Closed
Bug 562258
Opened 14 years ago
Closed 14 years ago
modal prompts should be made tab-modal
Categories
(Core :: General, defect)
Core
General
Tracking
()
Tracking | Status | |
---|---|---|
status2.0 | --- | ? |
People
(Reporter: Dolske, Assigned: Dolske)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 2 obsolete files)
13.10 KB,
patch
|
Details | Diff | Splinter Review |
[This is bug 59314, but please don't dupe or blocks/depends. It's old and noisy, and I'd like to get keep a high signal-to-noise ratio as this gets started.] We want to push to reduce the number of modal prompts in the next Firefox release. Modal dialogs suck for all kinds of obvious UI reasons that I won't go into here. I've started work on a patch that, as a first step, makes alert/confirm/prompt into tab-modal prompts. (Just as notification bars at the moment, that will eventually change.) Next step, if we get this all sorted out, would be to do the same for nsIAuthPrompt2.
Assignee | ||
Comment 1•14 years ago
|
||
First rough take. Looking for feedback on the general code implementation/design, not the UI. Haven't addressed any E10S issues here yet, and the needs of people embedding Gecko is just roughly sketched.
Comment 2•14 years ago
|
||
How does this kind of approach work with windowed plugins for example. And note, nsIPromptService is frozen interface, so IMO it should still work in generic case when embedding gecko.
Comment 3•14 years ago
|
||
We can and should break frozen APIs when they no longer make sense, and this is the perfect example. I'd rather remove nsIPromptService completely than try to add shims for existing embedders. Mozilla2 onward!
Comment 4•14 years ago
|
||
If we're ok to break APIs, then we need to say that clear and loudly. In DOM we could and will merge several interfaces asap it is ok to break frozen APIs.
Comment 5•14 years ago
|
||
We're ok to break APIs *if* the gain is sufficient. We don't want to break people without good justification.
Assignee | ||
Comment 6•14 years ago
|
||
(In reply to comment #2) > How does this kind of approach work with windowed plugins for example. An interesting question, because I don't understand how plugins would be involved with prompting! What was the issue you had in mind?
Comment 7•14 years ago
|
||
You have some (non-native)prompt open somewhere, right? How does that prevent user to interact with plugins?
Comment 8•14 years ago
|
||
We will need to block all user input to the tab (or multiple tabs in the same execution stack). We might also white out the tab a bit to make it clear that it is now inactive until the prompt is dealt with. So this would of course also cover any plugins in that tab's content area. Dolske and I have been talking about the UI for the past few days, and I'll hopefully have some mockups ready soon.
Assignee | ||
Comment 9•14 years ago
|
||
(In reply to comment #7) > You have some (non-native)prompt open somewhere, right? > How does that prevent user to interact with plugins? Ah. I'm not sure yet. We're talking about having the tab-modal UI be something that overlays the whole tab area (<stack>? <panel>? dunno). Presumably that can be made to block interaction with the page because it will simply have a higher z-index than the content. But maybe additional blocking/freezing needs to be done? [I'm assuming bug 130078 will be fixed to allow this UI, though as a <panel> it might not be needed.]
Comment 10•14 years ago
|
||
For Firebug, there's a need to have tab-specific panels, so implementing a means of showing and hiding panels per tab (or per window or per application) may be useful enhancement.
Comment 11•14 years ago
|
||
Neil: is their any way we could create a tab modal panel that could potentially be dragged outside of the tab? We are thinking about this for two different cases: httpauth: how can you really tell that this is a real prompt? Sites could spoof our current window, but since you can drag it outside of the content area it is clearly real. Not sure how much I care about this though, and is at best a silly concession to a security UI debate. javascript alerts/prompts: they could be overlapping content that the user needs to see to respond, so moving the prompt out of the way is reasonably important for some use cases.
Comment 12•14 years ago
|
||
Once titlebars on panels are supported, then, yes, moving them would be easy. Also, independently of that, click-and-drag-background moving is possible as well.
Updated•14 years ago
|
Blocks: cuts-focus
Comment 13•14 years ago
|
||
Just adding my current list of modal dialogs here: 1. Javascript alerts/prompts, 2. htauth prompts, 3. master password Are there other major categories of things that can lock up a window?
Comment 14•14 years ago
|
||
Maybe we should focus this bug on alert/confirm/prompt, which are simple. the HTTP password and master-password prompts are a little difficult because you may end up with multiple tabs asking for the same auth data, and you have to decide whether to auto-submit the blocked tab B when the user enters the password in blocked tab A. There's the infamous POSTDATA dialog, which could/should probably just be an error page.
Comment 15•14 years ago
|
||
window.showModalDialog() can too, unless that was covered by item nr 1 above.
Comment 16•14 years ago
|
||
(In reply to comment #13) > Just adding my current list of modal dialogs here: > > 1. Javascript alerts/prompts, JavaScript slow script/debug dialog, if that's not included in 1.
Comment 17•14 years ago
|
||
Is it feasible to have a window-modal dialogue which does not block certain key elements of the user interface? In Mac OS X, for instance, Firefox hides all menus but the application ("Firefox") menu while a modal dialogue is open, even though it doesn't have to (an I would guess it takes more work to make that happen than not). Safari (for Mac), for comparison, leaves all its menus (and sub-menus) visible and enabled, but just disables all its menu items except "Hide Safari", "Hide Others", and "Quit Safari". Safari's "Quit Safari" menu takes effect immediately, despite any modal dialogue being open; it even works if there are multiple windows and/or tabs open (despite being set to warn first in that case -- which it then doesn't.) Firefox also leaves its "Quit Firefox" menu enabled and functional, but it doesn't take effect immediately if there are multiple windows and/or tabs open (and it is set to warn about them) -- in which case it waits until after the modal dialogue is answered to ask the user whether they want to save their tabs, and then quits if they click "Quit". In that way, Firefox's behaviour is closer to what I think the typical user would expect. I think the Quit prompt should displace the modal dialogue (cancelling an alert or making a confirm or prompt or such wait for if the user cancels quitting). Interestingly, Firefox also leaves enabled its "Preferences" menu item, which is also more than Safari does -- and it works too, and on opening the Preferences window, all the menus return and are enabled again. Ideally, all the menus should remain visible and enabled, and specific menu items such as "Close Window", "Close Tab", and perhaps one which might've been added by an extension which specified that said menu item should remain enabled (such as one to do with debugging, if for instance, I would like to have a JavaScript debugger break immediately after the alert I'm seeing): function f(){ ... a=g(); if(!a) alert("debug: g() didn't return an a."); /* <-- while this alert is still open, I select "Break & Debug Script" from the still-visible-and-enabled "Tools" menu, and after I answer the modal dialogue, I end up in a debugger: */ // <-- here, before h(a) is called, at which point I would loose the information I'm looking for. h(); ... }
Comment 18•14 years ago
|
||
> Are there other major categories of things that can lock up a window?
"Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party. ... [Continue] [Cancel]" - is window-modal.
Presumably it's part of a family of similar security warnings. I seem to remember a similar one about images; something like "Some elements on this page are not encrypted [Show all]".
Assignee | ||
Comment 19•14 years ago
|
||
Updated WIP patch.
Attachment #442013 -
Attachment is obsolete: true
Updated•14 years ago
|
Comment 20•14 years ago
|
||
Comment on attachment 448461 [details] [diff] [review] Patch v.1 (WIP) >+ let p; >+ if (this.doModal || !domWin) >+ p = new ModalPrompter(domWin); >+ else >+ p = new TabPrompter(domWin); In this and all the other cases like it, can the ternary operator not be used to cut down on the excess lines? Seems like that would be cleaner from a code perspective... let p = (this.doModal || !domWin) ? new ModalPrompter(domWin) : new TabPrompter(domWin); ... unless JS doesn't make that easily possible for some reason.
Comment 21•14 years ago
|
||
JS certainly supports ?:, and JS style (C++ but who's counting) favors initializing a declaration with ?: if you can. If there's an if-else chain with fallible calls out of the current function, then not. So yeah, you could write let p = (...) ? new ModalPrompter(domWin) : new TabPrompter(domWin); or even let p = new ((...) ? ModalPrompter : TabPrompter)(domWin); to common the "new" and "(domWin)" parts. /be
Assignee | ||
Comment 22•14 years ago
|
||
Updated to reflect current changes from bug 563274.
Attachment #448461 -
Attachment is obsolete: true
Comment 23•14 years ago
|
||
(In reply to comment #13) window.print() > Just adding my current list of modal dialogs here: 1. Javascript alerts/prompts, 2. htauth prompts, 3. master password 4. JavaScript slow script/debug dialog, Comment 15 5. window.showModalDialog() Comment 16 6. ...sent over an unencrypted connection, Comment 18 7. Some elements ... not encrypted , Comment 18 8. window.print()
Comment 24•14 years ago
|
||
(In reply to comment #23) The JavaScript crypto stuff is modal, and can take a while to run for large keys. > (In reply to comment #13) > window.print() > > > Just adding my current list of modal dialogs here: > 1. Javascript alerts/prompts, > 2. htauth prompts, > 3. master password > 4. JavaScript slow script/debug dialog, Comment 15 > 5. window.showModalDialog() Comment 16 > 6. ...sent over an unencrypted connection, Comment 18 > 7. Some elements ... not encrypted , Comment 18 > 8. window.print() 9. crypto.generateCRMFRequest() or form with <keygen> element
Assignee | ||
Comment 26•14 years ago
|
||
Prototyping done, moving over to bug 562258 per comment 0.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Comment 27•14 years ago
|
||
(In reply to comment #24) > > 1. Javascript alerts/prompts, > > 2. htauth prompts, > > 3. master password > > 4. JavaScript slow script/debug dialog, Comment 15 > > 5. window.showModalDialog() Comment 16 > > 6. ...sent over an unencrypted connection, Comment 18 > > 7. Some elements ... not encrypted , Comment 18 > > 8. window.print() > 9. crypto.generateCRMFRequest() or form with <keygen> element 10. POSTDATA dialog, Comment 14
Comment 28•14 years ago
|
||
(In reply to comment #27) > (In reply to comment #24) > 1. Javascript alerts/prompts, > 2. htauth prompts, > 3. master password > 4. JavaScript slow script/debug dialog, Comment 15 > 5. window.showModalDialog() Comment 16 > 6. ...sent over an unencrypted connection, Comment 18 > 7. Some elements ... not encrypted , Comment 18 > 8. window.print() > 9. crypto.generateCRMFRequest() or form with <keygen> element > 10. POSTDATA dialog, Comment 14 11. window.onbeforeunload event
Comment 29•14 years ago
|
||
> 1. Javascript alerts/confirm/prompts, > 2. htauth prompts, > 3. master password > 4. JavaScript slow script/debug dialog, Comment 15 > 5. window.showModalDialog() Comment 16 > 6. ...sent over an unencrypted connection, Comment 18 > 7. Some elements ... not encrypted , Comment 18 > 8. window.print() > 9. crypto.generateCRMFRequest() or form with <keygen> element > 10. POSTDATA dialog, Comment 14 > 11. window.onbeforeunload event 12. non-associated protocol dialog, Bug 599662
Comment 30•14 years ago
|
||
Why is this resolved duplicate of a bug that only fixes one item on the list? Would it help to create separate bugs for each of these, and list them as blocking this one? (and then reopen this bug) (I'm only aware of bug 59314 for item #1 and bug 564337 for item #5 so far).
Comment 31•14 years ago
|
||
> Why is this resolved duplicate of a bug that only fixes one item on the list? Because this bug was filed as a duplicate of bug 59314. See comment 0. "The list" is just an attempt to hijack the bug. Please file separate bugs for items on "the list" as needed.
Comment 32•14 years ago
|
||
Done, bug 616843 for anyone interested.
You need to log in
before you can comment on or make changes to this bug.
Description
•