Closed Bug 123913 Opened 20 years ago Closed 11 years ago
[RFE] tab-specific alerts are window-modal and should be tab-modal (need "sheets" widgets on non-Mac
assuming bug 123908 is fixed on Mac OS X, that platform will have tab-modal alert messages. wouldn't be nice if other platforms had the same thing? To make this possible, I'd like to RFE a widget like Mac OS X's "sheets" which would be used for this purpose on apps which don't have native sheets. Heck, if you're making them from scratch, you could even make them *better* than Apple's sheets, and have them be attached to frames or tabs rather than just to windows. -matt
*** This bug has been marked as a duplicate of 59314 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
adding to summary to make bug easier to find. Boris, I don't think bug 123913 is a straight dup of bug 59314. Specifically, bug 123913 is an RFE for a crossplatform implementation of "sheets" (a la Mac OS X) to implement the content-modality. Also, bug 123913 presuposes a fix in tabbed browsing which may well be addressed (or not addressed) regardless of what happens in bug 59314. For example, bug 59314 might be fixed by providing a magic keycommand which aborts all scripts. I think... at least the bug 59314 comments indicate such... actually, bug 59314 seems to have a bit of a split personality, and might be best off *closed* in favor of two clear bugs: bug 123913 (which depends on bug 123908) and bug 61098) From the other direction, bug 123913 could be fixed, and bug 59314 would still hold: once you clicked into the offending tab, the tab would give you a sheet with the alert and you might still have an application totally locked if the stream of alerts never ended. So, since each bug can be fixed independantly, I don't think they're dups, and I'm de-duping... -matt
Status: RESOLVED → REOPENED
Depends on: 123908
Resolution: DUPLICATE → ---
Target Milestone: --- → Future
*** Bug 125829 has been marked as a duplicate of this bug. ***
*** Bug 144055 has been marked as a duplicate of this bug. ***
m_mozilla (matt): I see this bug depends upon Bug 123908, but I'm really not convinced that a fix for this bug is impossible until 123908 is fixed. It looks to me like this bug and 123908 are siblings. Ask yourself if any proper dependency between them exists at all: couldn't you fix one even if you avoided fixing the other? This bug is an RFE, whereas 123908 seems to be more of a straight up bug (you filed both, so I presume you know). It seems just as logical to have 123908 dependant upon this bug, since fixing the general case would probably fix the OS-specific 123908 as well. Ultimately, I think either 1) 123908 and 123913 _are_ duplicates of 59314; or 2) 123908 and 59314 are duplicates of 123913. This is because I suppose there must be one really good way to fix all of them at once (such as the fix proposed here in 123913). On an unrelated point, consider adding Bug 121209 to block 123908 and/or 123913.
*** Bug 223687 has been marked as a duplicate of this bug. ***
*** Bug 225308 has been marked as a duplicate of this bug. ***
*** Bug 240824 has been marked as a duplicate of this bug. ***
*** Bug 246948 has been marked as a duplicate of this bug. ***
Summary: [RFE] tab-specific alerts are app-modal and should be tab-modal (need "sheets" widgets on non-MacOSX) → [RFE] tab-specific alerts are window-modal and should be tab-modal (need "sheets" widgets on non-MacOSX)
*** Bug 248872 has been marked as a duplicate of this bug. ***
*** Bug 257388 has been marked as a duplicate of this bug. ***
*** Bug 260751 has been marked as a duplicate of this bug. ***
*** Bug 267103 has been marked as a duplicate of this bug. ***
*** Bug 268307 has been marked as a duplicate of this bug. ***
*** Bug 271430 has been marked as a duplicate of this bug. ***
*** Bug 263047 has been marked as a duplicate of this bug. ***
Fixing this (for modal dialogs as well as modal alerts) would likely fix the latest Secunia report on Firefox, SA15489: http://secunia.com/advisories/15489/ This would be far better than adding the URL to the title, IMO, although that would be an adequate stop-gap measure.
This is hard to implement correctly. It requires that the underlying APIs are non-blocking, since you want other windows and tabs to function correctly while a given tab is "blocked" with a tab-modal alert. This would require significant re-architecture of many underlying systems.
*** Bug 283551 has been marked as a duplicate of this bug. ***
*** Bug 308905 has been marked as a duplicate of this bug. ***
*** Bug 308849 has been marked as a duplicate of this bug. ***
*** Bug 310309 has been marked as a duplicate of this bug. ***
*** Bug 314156 has been marked as a duplicate of this bug. ***
I think this issue deserves a higher priority than "enhancement", since streams of dialog boxes are used in social-engineering attacks by malware pages to condition the user into clicking "yes" repeatedly until they encounter a software installation dialog, and then click "yes" on it as they have clicked on the previous ten dialog boxes... For the case of streams of alert boxes, would a "close this page"/"exit firefox"/"go to home page" or other form of "bail-out" button on alert boxes, clearly marked as distinct from the buttons generated by the alert box itself, be useful? An alternative approach might be to enforce a short delay between the display of successive modal dialogs, in order to allow the user a short pause in which to try to naviagate away from the page or exit the browser. It might be reasonable to gradually increase this delay as the number of successive dialog boxes increases, resetting it to zero as soon as any other form of user interaction occurs.
Talking about modal dialogs is just wrong. A web browser should treat the web page as the place for dialogs, so that they're naturally non-modal, tab-specific, and can be switched away from. (sheets in Mac OS X comes closest.)
I think we all agree that this is a good thing. But it's extremely hard to implement (the whole backend modality model has to change).
*** Bug 330160 has been marked as a duplicate of this bug. ***
*** Bug 331239 has been marked as a duplicate of this bug. ***
*** Bug 334581 has been marked as a duplicate of this bug. ***
I agree that alert(), prompt() etc, should be tab-modal instead of window-modal. I also think that maybe they shouldn't be an OS widget(?) at all, but a display that's generated by Firefox inside the page, like the "Server not found" messages were revamped away from modal OS dialogs into special pages. That way it would be the same for every OS (Windows alert() dialogs look ugly), and would be tab-modal, too. This is a mock-up of what I think it should do: http://mysite.verizon.net/negatron/custom_alert.htm I'm not the best coder, and I just ripped off the alert() overloading from another site. Added some enhancements like "dimming" the background and using a chrome image. This could probably be made into a browser or greasemonkey script or something as a workaround, but I don't know enough to do that myself.
Personally, I think the simplest solution would be to delay the showing of the alert box until the tab containing its calling page receives focus.
(In reply to comment #33) > Personally, I think the simplest solution would be to delay the showing of the > alert box until the tab containing its calling page receives focus. That's just not possible without asynchronous up-call APIs (which Gecko, NSS etc don't have).
*** Bug 348327 has been marked as a duplicate of this bug. ***
*** Bug 353675 has been marked as a duplicate of this bug. ***
@Jon B: Cool! It doesn't look 100% perfect but it's a great proof of concept. Is it possibl to make a Firefox Extension that overloads the window.alert and window.promt functions for each webpage? That would be a nice workaround!
(In reply to comment #42) > Is it > possibl to make a Firefox Extension that overloads the window.alert and > window.promt functions for each webpage? That would be a nice workaround! I'm sure it's possible, as the page I attached is just a modified version of a script meant to overload those functions, but I don't know how to create an extension. I mentioned the same thing in https://bugzilla.mozilla.org/show_bug.cgi?id=123913#c32 :-)
How about using an nsIAlert to notify the user that there is a hidden dialog waiting? (i.e. growl)
Having an alert to notify the user that there is a hidden dialog waiting is good, but that should be an extension. Why not just colour the tab which has the alert and remove the possibility of that tab alert interrupting other tab activities? I do like the mock up alert suggested by Jon B, it's a bit fancy but it looks more modern, and less intrusive than the normal alert box.
Why in the world did I get this bug alert when I didn't sign up for it? Did I anger of one of the moderators by rebuking them? Revenge bugzilla spam eh?
Status: REOPENED → NEW
QA Contact: jrgmorrison → xptoolkit.widgets
This might be harder to fix now that we support showModalDialog (bug 194404) in addition to alert/prompt/confirm :(
Is there any reason this can't be fixed with an extension? It's taking way too long otherwise. The code I found for my attachment hijacks the alert() function to display it as a div in the web page itself instead of an OS dialog. Surely an extension could be written that does the same thing for all modal dialogs.
Bug 520841 is an immediate security concern and this Bug should be moved from an "enhancement" to an "immediate" or more important level of concern. The presence of scriptable modal dialog boxes circumvents security issues. Please read https://bugzilla.mozilla.org/show_bug.cgi?id=520841
(In reply to comment #2) > For example, bug 59314 might be fixed by providing a magic keycommand which > aborts all scripts. I think... at least the bug 59314 comments indicate such... The summary, "Alerts should be content-modal, not window-modal", is more relevant than random comments.
Status: NEW → RESOLVED
Closed: 20 years ago → 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 59314
You need to log in before you can comment on or make changes to this bug.