Display dialog boxes more prominently #1898

Closed
B0073D opened this Issue Aug 29, 2016 · 5 comments

Comments

Projects
None yet
2 participants
@B0073D

B0073D commented Aug 29, 2016

I would like to be able to configure qutebrowser to display dialog boxes and other items requiring input to be displayed more prominently.

For example, SSL warnings and other things that often steal focus are currently displayed in the status bar at the bottom. A lot of the time I do not see these right away. Only when I wonder why the page is not loading do I see these.

A preferred method or option would be to display them in the center of the screen, perhaps in a 'Windows 10' style bar across the screen with the content grayed out?

I believe this would improve usability.

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Aug 29, 2016

Collaborator

Making them modal (i.e. not allowing the user to interact with the page while they're open) would also make the code a lot simpler, and is something which was in the back of my mind for a while already.

I think Otter Browser is a good example:

js

I imagine something similar, but of course with keyboard navigation in mind.

Collaborator

The-Compiler commented Aug 29, 2016

Making them modal (i.e. not allowing the user to interact with the page while they're open) would also make the code a lot simpler, and is something which was in the back of my mind for a while already.

I think Otter Browser is a good example:

js

I imagine something similar, but of course with keyboard navigation in mind.

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Sep 14, 2016

Collaborator

Raising the priority of this as I hope it'd make it possible to get rid of a lot of complexity in the code.

Collaborator

The-Compiler commented Sep 14, 2016

Raising the priority of this as I hope it'd make it possible to get rid of a lot of complexity in the code.

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Sep 15, 2016

Collaborator

A small overview about what kind of prompts we have currently, classified according to these properties:

  • Some of them are synchronous, which means we need the answer for that question before the answer to any older synchronous questions. We also might want to consider making them application-modal to minimize the actions the user can do, which minimizes the possibility for edge-cases (crashes/hangs) of which there are a lot otherwise.
  • Some of them are designed to be page modal, i.e. the page is blocked until they are answered
  • Some of them are global, i.e. not associated with a specific tab or window
  • Some of them are the result of a direct prompt input, so a full-tab dialog might be too intrusive?

The questions:

  • Javascript alert: modal
  • Javascript confirm: modal, sync
  • Javascript prompt: modal, sync
  • Feature permission: none
  • SSL errors: modal?, sync
  • HTTP authentication: modal?, sync
  • Proxy authentication: modal, sync
  • Download location / overwrite-confirm:
    • WebKit: origin
    • WebEngine: sync, global
  • Quickmark name: prompt
  • Quickmark override question: prompt
  • "Open external application": modal
  • Quit confirmation: modal, sync, global

Some considerations:

  • Do we want per-tab questions instead of global ones? I think yes, as it makes it easier to see why something happens (e.g. where an SSL error originated from).
  • If we do, what about synchronous questions? The best I could come up with is something like "The question in tab x needs to be answered before this one, use :prompt-accept (Enter) to go there".
  • For the global one(s), we can probably just ask a window modal question in every window...
  • Do we want a full-tab question thingy for a quickmark name? I'd say no, but then we'd need to keep the old code around too?
  • Maybe don't have full-window questions at all, but definitely bigger than the statusbar (say, 100px or so), and have the page blurred/darkened?
Collaborator

The-Compiler commented Sep 15, 2016

A small overview about what kind of prompts we have currently, classified according to these properties:

  • Some of them are synchronous, which means we need the answer for that question before the answer to any older synchronous questions. We also might want to consider making them application-modal to minimize the actions the user can do, which minimizes the possibility for edge-cases (crashes/hangs) of which there are a lot otherwise.
  • Some of them are designed to be page modal, i.e. the page is blocked until they are answered
  • Some of them are global, i.e. not associated with a specific tab or window
  • Some of them are the result of a direct prompt input, so a full-tab dialog might be too intrusive?

The questions:

  • Javascript alert: modal
  • Javascript confirm: modal, sync
  • Javascript prompt: modal, sync
  • Feature permission: none
  • SSL errors: modal?, sync
  • HTTP authentication: modal?, sync
  • Proxy authentication: modal, sync
  • Download location / overwrite-confirm:
    • WebKit: origin
    • WebEngine: sync, global
  • Quickmark name: prompt
  • Quickmark override question: prompt
  • "Open external application": modal
  • Quit confirmation: modal, sync, global

Some considerations:

  • Do we want per-tab questions instead of global ones? I think yes, as it makes it easier to see why something happens (e.g. where an SSL error originated from).
  • If we do, what about synchronous questions? The best I could come up with is something like "The question in tab x needs to be answered before this one, use :prompt-accept (Enter) to go there".
  • For the global one(s), we can probably just ask a window modal question in every window...
  • Do we want a full-tab question thingy for a quickmark name? I'd say no, but then we'd need to keep the old code around too?
  • Maybe don't have full-window questions at all, but definitely bigger than the statusbar (say, 100px or so), and have the page blurred/darkened?
@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Sep 20, 2016

Collaborator

Behavior/design in other browsers

Chromium

Chromium uses floating dialog boxes over a given page:

chromiumauth

chromiumdialog

Those can be application modal and prevent switching of tabs, or they can allow it (like the auth dialog).

When tab switching is forbidden, the dialog has a slight shake/nudge when trying to do so. When doing anything in a different Chromium window, nothing happens and the blocked window sends an urgency hint.

For file path dialogs, a separate window is opened.

Firefox

Firefox uses a dialog over a dimmed down page:

firefoxdialog

Those are never modal, but I guess that's just something Firefox/Gecko allows them to do internally.

Those are only used for javascript stuff though - e.g. website authentication is a separate window popping up.

Other thoughts

Originally a Windows-like thing was mentioned:

restartwin10

However I'd rather not have something which remembers people of Windows 😆

For :quickmark-save where a full-screen dialog would be rather intrusive, couldn't we just bind that to something setting the command text to :quickmark-add {url} instead? However that might be less intuitive, and what do we do for duplicates?

For selecting files/directories, can we show a dialog overlay like that with an input (like now) plus a graphical file picker?

For certificate errors, we get an error page instead of a dialog-like thing in Chromium/Firefox - though I think the API we get doesn't allow us to do that? Or maybe we can display an error page and then do another fresh load after the user selected an option? (edit: we can't securely, QTBUG-51176)

Collaborator

The-Compiler commented Sep 20, 2016

Behavior/design in other browsers

Chromium

Chromium uses floating dialog boxes over a given page:

chromiumauth

chromiumdialog

Those can be application modal and prevent switching of tabs, or they can allow it (like the auth dialog).

When tab switching is forbidden, the dialog has a slight shake/nudge when trying to do so. When doing anything in a different Chromium window, nothing happens and the blocked window sends an urgency hint.

For file path dialogs, a separate window is opened.

Firefox

Firefox uses a dialog over a dimmed down page:

firefoxdialog

Those are never modal, but I guess that's just something Firefox/Gecko allows them to do internally.

Those are only used for javascript stuff though - e.g. website authentication is a separate window popping up.

Other thoughts

Originally a Windows-like thing was mentioned:

restartwin10

However I'd rather not have something which remembers people of Windows 😆

For :quickmark-save where a full-screen dialog would be rather intrusive, couldn't we just bind that to something setting the command text to :quickmark-add {url} instead? However that might be less intuitive, and what do we do for duplicates?

For selecting files/directories, can we show a dialog overlay like that with an input (like now) plus a graphical file picker?

For certificate errors, we get an error page instead of a dialog-like thing in Chromium/Firefox - though I think the API we get doesn't allow us to do that? Or maybe we can display an error page and then do another fresh load after the user selected an option? (edit: we can't securely, QTBUG-51176)

@The-Compiler

This comment has been minimized.

Show comment
Hide comment
@The-Compiler

The-Compiler Sep 22, 2016

Collaborator

I think I'm going for something attached to the statusbar - first draft:

auth

For files, this might even include a file browser/list.

Not 100% sure how to handle modality and other constraints yet, and if prompts will be per-tab (i.e., hidden when you switch to another tab).

Collaborator

The-Compiler commented Sep 22, 2016

I think I'm going for something attached to the statusbar - first draft:

auth

For files, this might even include a file browser/list.

Not 100% sure how to handle modality and other constraints yet, and if prompts will be per-tab (i.e., hidden when you switch to another tab).

@The-Compiler The-Compiler added this to the new prompts milestone Oct 3, 2016

@The-Compiler The-Compiler referenced this issue Oct 28, 2016

Merged

New prompts #2054

17 of 17 tasks complete

@The-Compiler The-Compiler closed this in #2054 Nov 4, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment