Note: There are a few cases of duplicates in user autocompletion which are being worked on.

[RFE] tab-specific alerts are window-modal and should be tab-modal (need "sheets" widgets on non-MacOSX)

RESOLVED DUPLICATE of bug 59314

Status

()

Core
XUL
--
enhancement
RESOLVED DUPLICATE of bug 59314
16 years ago
3 years ago

People

(Reporter: m_mozilla, Unassigned)

Tracking

Trunk
Future
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
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

Comment 1

16 years ago

*** This bug has been marked as a duplicate of 59314 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 2

16 years ago
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 → ---

Comment 3

16 years ago
-> future
Target Milestone: --- → Future

Comment 4

16 years ago
*** Bug 125829 has been marked as a duplicate of this bug. ***

Comment 5

15 years ago
*** Bug 144055 has been marked as a duplicate of this bug. ***

Comment 6

15 years ago
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.
(Reporter)

Comment 7

15 years ago
I think you're right, David.

Bug 123908
    tab-specific alerts are window-modal in MacOS X and should be tab-modal

Bug 123913 (this bug)
    tab-specific alerts are app-modal and should be tab-modal
    (need "sheets" widgets on non-MacOSX)

You *could* fix bug 123913 without fixing bug 123908, but at the time I'd
indicated the dependancy, I wasn't thinking of any other ways to fix bug 123913.

I'm not certain that any of the alternatives really do the job though, so I'm
not certain that I should remove the dependancy. For example, take the idea of
changing the backround color of a tab when that tab has an alert... That gives
you a clear "it's this tab that has some alert pending" message, but once you
click on that tab, suppose the javascript is going to give you a near-infinite
stream of alerts. Are those alerts tab-modal (so you can ignore them and switch
to another tab) or are they still window-modal (you can't change tabs because
you're forced to keep dismissing alerts).

It sounds like the other proposed fixes do half the job. They notify you that
you have an alert in a tab-specific fashion, but once you look at the alert,
you're not looking at a tab-modal alert. If anything, I can imagine that
tab-modal alerts could be implemented first, and then users would have trouble
knowing that their background tabs had pending alerts. *That's* the bug that the
other solutions seem to fix in my mind, but that bug doesn't really exist yet.


In my mind, things could be fixed in something like the following order:
    sheets on MacOS X would be replaced with window-modal XPI sheets
    window-modal XPI sheets would be made content-modal (tab-modal)
    XPI sheets would be applied to non MacOS X platforms
    some notification of "tab has pending sheet" would be created


So, I think I'll leave the dependancy in place. If anyone thinks I'm off-track
here, feel free to change it yourself. I'm not implementing any of this, and I'd
expect that whomever does that will have a much clearer idea of what depends on
what. :)

I will make a note in bug 121209 about the discussion here though.

-matt

Comment 8

14 years ago
*** Bug 223687 has been marked as a duplicate of this bug. ***

Comment 9

14 years ago
*** Bug 225308 has been marked as a duplicate of this bug. ***

Comment 10

14 years ago
*** Bug 240824 has been marked as a duplicate of this bug. ***

Comment 11

13 years ago
*** Bug 246948 has been marked as a duplicate of this bug. ***

Updated

13 years ago
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)

Comment 12

13 years ago
*** Bug 248872 has been marked as a duplicate of this bug. ***

Comment 13

13 years ago
*** Bug 257388 has been marked as a duplicate of this bug. ***

Comment 14

13 years ago
*** Bug 260751 has been marked as a duplicate of this bug. ***
Blocks: 262887

Comment 15

13 years ago
*** Bug 267103 has been marked as a duplicate of this bug. ***
*** Bug 268307 has been marked as a duplicate of this bug. ***

Comment 17

13 years ago
*** Bug 271430 has been marked as a duplicate of this bug. ***

Comment 18

13 years ago
*** Bug 263047 has been marked as a duplicate of this bug. ***

Comment 19

12 years ago
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.
Flags: blocking-aviary2.0?

Comment 20

12 years ago
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. ***

Comment 22

12 years ago
*** Bug 308905 has been marked as a duplicate of this bug. ***
*** Bug 308849 has been marked as a duplicate of this bug. ***

Comment 24

12 years ago
*** Bug 310309 has been marked as a duplicate of this bug. ***
*** Bug 314156 has been marked as a duplicate of this bug. ***

Comment 26

12 years ago
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.


Comment 27

12 years ago
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.)

Comment 28

12 years ago
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).

Updated

12 years ago
Flags: blocking-firefox2? → blocking1.8.1-
*** 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. ***

Comment 32

11 years ago
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.

Comment 33

11 years ago
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.

Comment 34

11 years ago
(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. ***

Comment 36

11 years ago
(In reply to comment #26)
> 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...
Not only that, but alert() in a loop hangs the browser because the dialog is modal. This not only could be used in an attack but also gets very annoying when you use it for debugging Javascripts. This bug (as any bug that forces the user to close the browser) should be marked Major if nothing else.
*** Bug 353675 has been marked as a duplicate of this bug. ***

Updated

11 years ago
Duplicate of this bug: 375937

Comment 39

11 years ago
Created attachment 260154 [details]
Mock-up of proposed behavior

Comment 40

11 years ago
Created attachment 260155 [details]
Regular OS-style dialog box

Comment 41

11 years ago
Created attachment 260156 [details]
Proposed tab-specific dialog replacement

Comment 42

11 years ago
@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!

Comment 43

11 years ago
(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  :-)

Comment 44

11 years ago
How about using an nsIAlert to notify the user that there is a hidden dialog waiting? (i.e. growl)

Comment 45

11 years ago
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. 

Comment 46

11 years ago
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?

Comment 47

11 years ago
_Please_, don't start a long discussion about the possible UI of this, unless you're going (and able) to fix the whole bug.

The main problem with this is the modality of alert() and similar methods: the code that called alert() must be suspended until the user dismisses the alert. The call stack to the alert() call can contain both JS and native frames and it has to be preserved until the user dismisses the alert.

The way it is implemented now is that when opening window-modal dialogs like alert() a new, nested event loop is spun in nsXULWindow::ShowModal until the dialog is dismissed (so the other windows are still functional). This causes various problems, which will become more visible, if this method is extended to work with tabs:

For example, there's a bug about timeouts firing in a window that's supposed to be frozen by an alert(), other windows can modify the window that called alert() while the dialog is still open, successive alert() calls in different windows don't work well - try opening two windows, opening the javascript:alert("1.1");alert("1.2"); in the first window, then javascript:alert("2.1");alert("2.2"); in the second window, then dismissing the "1.1" alert. You'll see that the "1.2" alert will not appear, until you dismiss both alerts in the window #2.

There are no obvious alternatives to the way it works right now - I don't know of a way to do continuations in a portable way in C++, and abusing threads to preserve the stack for each tab seems hard to do right.

There are also comments on feasibility of this at http://blog.mozilla.com/faaborg/2007/03/06/would-you-like-to-redesign-notification-in-firefox-yes.-not-now.-never./
(see the comments) although I don't agree with some of them.
Status: REOPENED → NEW
QA Contact: jrgmorrison → xptoolkit.widgets
Duplicate of this bug: 376424
Duplicate of this bug: 382892

Comment 50

10 years ago
This might be harder to fix now that we support showModalDialog (bug 194404) in addition to alert/prompt/confirm :(

Updated

10 years ago
Duplicate of this bug: 399583

Updated

10 years ago
Duplicate of this bug: 399631

Updated

10 years ago
Duplicate of this bug: 424358

Comment 54

10 years ago
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.
Duplicate of this bug: 442449

Updated

9 years ago
Duplicate of this bug: 444792
Duplicate of this bug: 460434

Updated

9 years ago
Blocks: 332195
Assignee: jag → nobody
Duplicate of this bug: 520841

Comment 59

8 years ago
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
Last Resolved: 16 years ago7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 59314

Updated

3 years ago
No longer blocks: 332195
You need to log in before you can comment on or make changes to this bug.