Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display dialog boxes more prominently #1898

B0073D opened this issue Aug 29, 2016 · 5 comments

Display dialog boxes more prominently #1898

B0073D opened this issue Aug 29, 2016 · 5 comments


Copy link

@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.

Copy link

@The-Compiler 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:


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

Copy link

@The-Compiler 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.

Copy link

@The-Compiler 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?
Copy link

@The-Compiler The-Compiler commented Sep 20, 2016

Behavior/design in other browsers


Chromium uses floating dialog boxes over a given page:



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 uses a dialog over a dimmed down page:


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:


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)

Copy link

@The-Compiler The-Compiler commented Sep 22, 2016

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


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 mentioned this issue Oct 28, 2016
17 of 17 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants