User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101119 Firefox/4.0b8pre Build Identifier: With the new tab-modal prompts, if such a prompt is used, the page contents are blurred in an effort to draw attention to the prompt. This seems really jarring from what I've seen of it. I think some other effect should be used instead. (Maybe slightly dim/darken the page?) Reproducible: Always

Please notice, that IMHO bug 613754 is not a duplicate of this bug, as it refers to the alert box itself, not the blurring the page (unless you change the title of this bug to something more general, like "Change the way of displaying tab-modal prompts")

Yeah, bug 613754 doesn't seem like a dupe to me. jk1700 is talking about the "see-throughness" of the prompt itself, not the blurriness of the page contents.

OK, I can re-open it, both the prompt and the page blurring is just all-around bad, making a bad combo which I would think could be fixed under one bug...

That's why I mentioned change this bug title to more general, no need to reopen bug 613754

Another problem of this solution is performance: - I see delay about 200ms - 300ms until prompt appears - Showing hidden tab with prompt is delayed - Page blinks when prompt is shown for first time

I noticed the web is tended to lean more toward the darkening the page for other stuff like photo popups and not letting users use the page underneath, but blurring might be hard on the eyes for some users and hard to get used it since its a straight up blur not depth of field type, not to mention you cannot read the underlining contents if it was malicious or desirable.

Attached screen with one of many examples where the current effect produces bad results. Apart from that due to the computation intense gaussian blur my computer needs approximately two seconds to display the alert. Thus gaussian blurring is definitely not an option.

I cannot see what there is in bottom, therefore this returns confirmation complicated.

Not being able to read the underlying page before answering the prompt -> big fail. Dimming the page instead of blurring it would not only look better and make the prompt stand out more than it does now, but it would still leave the page readable, which is a must.

This patch replaces the blur effect with a CSS dimming effect. It doesn't remove effects.svg from any of the themes, though. It just ignores it. Would like feedback.

And what that patch looks like.

That looks absolutely perfect. Is the performance also better, or is it as slow as the blur?

It's much much better without blur, however the content of the page should be easly readable and here the contrast goes quite low and page is too dark. I think that opacity 0.3-0.4 would be much better

It's pretty instantaneous for me, although I'm on a faster machine. It does feel faster than the blur. (Maybe because that uses an SVG filter instead of plain CSS?)

+1 for less dark. It's hard to read for me in a dim room; this would be completely invisible in an office on a sunny day.

This should be fixed before beta 8.

Opacity level can be tweaked in a future patch (pages with dark backgrounds make the dimming effect hard to notice with lower opacity, fwiw), I'd just like the patch mechanics to be reviewed first. Nominating for blocking.

@Wes Kocher: The dimming effect looks really nice. I am not a reviewer, but some notes about your patch: You are using 4-space indentation, you should use 2-space indentation. Furthermore you lack a space after 'filter:' and 'background:'. Though I would remove the 'filter'-attribute altogether (or does 'browser' have some default filter?) Furthermore I do not really understand why the dimming effect is applied to 'tabmodalprompt'. It would make more sense for me to apply it to 'browser[tabmodalPromptShowing]'. Though I'm not sure about that. Furthermore the styling of 'tabmodalprompt' belongs to toolkit/themes/***/global/tabprompts.css imho. But as I mentioned, I'm not a reviewer.

Why do we need to see underlying content? If a web page ask for blocking browser window it saying also that this is important prompt\alert affecting all page a whole Blur effect is absolutely perfect for that Web masters and badly coded sites - that's the problem and we can't fix it and that will fade away after time

In response to comment 20: Never will a browser support your position. Most of the web pages are badly coded. Still Firefox displays them all. Nobody wants to use a browser who commits suicide on every tiniest error he encounters. That's exactly the reason why XML sucks that much - because of it's draconian error handling. confirm()s are often used to ensure that an action shall be performed. For this it is often helpful to check the contents of the issuing page (see example above). Thus it is indispensable to be able to see the contents of the issuing page!

Privat is right. My workplace uses a host of web technologies and when one goes bad, if there is a prompt up we need to see what is causing it, sometimes you see the problem output to the screen, and if it was blurred during this time, well no person in their right mind would use this build to diagnose the problem or take screenshots to file bugs. The other thing is anytime you have a form on the web and you need to confirm something before moving on, if you cannot see whats on the screen its useless for making a decision.

Guys, blurring is definetaly a bad idea! For example on itcafe.hu, the editor uses prompts. If i craete a link, a prompt shows up. Now i wanna copy something from the already written post to the prompt, but i cant, because i cant see it because of the blur! http://img221.imageshack.us/img221/6527/tabmodal.png Ant these new prompts are slow...

(partly In reply to comment #20) The modal prompt should differ from the old one in one point: tab modality. Any other change should be handled as a separate issue/bug. The old one did not blur or dim the page for 15 years (counting other browsers...) and nobody complained. The one who advocates the blur/dim/whatever must justify their case, not the other way around. To summarize: Blur is: - slow (performance) - obscures the page content (why?) - changes (almost) a decade long way of operation (again, why?)

(In reply to comment #24) > The one who advocates the blur/dim/whatever must justify their case, not the > other way around. > > To summarize: Blur is: > - slow (performance) > - obscures the page content (why?) > - changes (almost) a decade long way of operation (again, why?) I believe the idea was to make the little alert box stand out even when the site is loaded and messy (I have seen it numerous times how users apparently oversee a modal alert and are furiously trying to click on the app "behind" it). Additionally, its a way of trying to make clear to the user that the content of the page is not accessible as long as the alert is open. Last but not least, is this also how alerts created by JS widget frameworks (like JQuery UI) work. Now I understand there are cases when one still wants to see behind the alert, so IMHO it would be a great if a compromise could be found, for example an easy way for toggling the "veil" on-the-spot.

Comment 25 has a very good point, so what about a transition? --now that those are available on CSS. Since the idea is to let users notice the new window, you could dim the window and make a transition to make it transparent after, say, 1 or 2 seconds --or leave it semi-transparent (a bit dim). I'll try to put together a working sample (for Firefox) and upload it. Note: this could be combined with disabling all input for around .5 seconds.

@Comment 27: Not sure about this. I see two issues: a) There is too much movement. A large area of the content will be animated, which will distract from the prompt itself. b) What if the browser window is unfocused? Will the transition happen while I'm not seeing it? Or will it happen as soon as I focus back? The first solution isn't nice, because I will never see that the page was dim at some point and the second solution isn't nice either, as it creates the effect that the prompt was just created as I focused back (I don't know, whether this is an issue.) Other solutions like a "Dim background" checkbox in the alert() aren't nice either. They make the interface too bloated, imho. I think a reasonable solution is to dim the background, but only dim it slightly. This way the prompt still is emphasized, but the content in the background remains well readable. Maybe somebody can provide screenshot how it looks with .3 or .4 instead of .8?

(In reply to comment #25) I suppose there are a few possible compromises. One of them would be flashing the background/prompt when the user tries to ignore the prompt and click on the background. Another example would be blurring/dimming the content upon mouse over.

>The one who advocates the blur/dim/whatever must justify their case, not the >other way around. The goal is to focus the user's attention (and at the very least help them realize that there is now a prompt to respond to). However, that isn't mutually exclusive with the problems you mention: >To summarize: Blur is: > - slow (performance) > - obscures the page content (why?) > - changes (almost) a decade long way of operation (again, why?) A slight dim effect combined with the ability to shift the position of the dialog would avoid these problems and also make it obvious to the user that a dialog has appeared.

This (hopefully) addresses all of the non-reviewer review comments. I'm in the process of building with this patch (because I still can't open omni.jar with 7-zip so I can't just play with the files without building a non-omnijarred version). I think there might be issues with the opacity of the background in general (the dimmed part) and the opacity of the prompt itself. Not sure what opacity levels should be. Will request a proper review once I know that this actually works in my build. (In reply to comment #19) > You are using 4-space indentation, you should use 2-space indentation. Fixed. > Furthermore you lack a space after 'filter:' and 'background:'. Though I would > remove the 'filter'-attribute altogether (or does 'browser' have some default > filter?) Yeah, filter was just a leftover from me testing things via Stylish. They're removed completely in this patch. (Still haven't removed the actual SVG files, though...) > Furthermore I do not really understand why the dimming effect is applied to > 'tabmodalprompt'. It would make more sense for me to apply it to > 'browser[tabmodalPromptShowing]'. Though I'm not sure about that. I tried doing it to browser[tabmodalPromptShowing], but it didn't change anything. tabmodalprompt elements actually span the entire dimensions of the non-chrome parts of the browser. (Which could make fixing bug 613751 interesting, fwiw...) > Furthermore the styling of 'tabmodalprompt' belongs to > toolkit/themes/***/global/tabprompts.css imho. Done.

And what that patch looks like. Seems the actual prompt does have opacity itself. (You can see the text behind the prompt.) Not sure if that's desired.

Bug 613754 refers to the prompt opacity

Comment on attachment 493927 [details] [diff] [review] Dim v2 Going in a slightly different direction, I have an updated mockup from shorlander and will implement it shortly.

Oh, I should note Steven did the CSS and I just cleaned up the patch. I'm even going to steal the screenshot he made! :)

Comment on attachment 494282 [details] [diff] [review] Patch v.1 This doesn't seem to perform much better. I'm still seeing a significant delay before the prompts display and when switching to a tab with a prompt.

(In reply to comment #38) > This doesn't seem to perform much better. I'm still seeing a significant delay > before the prompts display and when switching to a tab with a prompt. Is it the loading of the effects.svg file itself that causes all of this delay? (Thus, any effect rendered from svg filters will have this?)

To continue comment 39, if it is the SVG itself that's the slowdown here, is there a way to speed the needed SVG up fundamentally? (existing bug even?)

No, it sounds like, and ought to be, that it's the painting that's slow (not loading of the SVG file). As far as making it faster: (1) profile to see if there's anything unexpected going on (2) hardware acceleration of some SVG filters might be a possibility, but I suspect (although it's really not my area) that it's probably a ways off and a good bit of work.

Would fixing bug 595671 help here?

I dont know if this is related to the blur, but for me it has a huge lag till a dialog is shown (>2 sec.) and then another huge lag and sometimes a hang of the browser (>10 sec.) until firefox handles any new input. Wanted to profile it with the debug build on Windows 7, but I can't run them because of an incorrect side-by-side configuration. Already installed MSVC++ 2005 Express and MSVC++ 2010 Express but none of them helped. :(

(In reply to comment #38) > This doesn't seem to perform much better. I'm still seeing a significant delay > before the prompts display and when switching to a tab with a prompt. Is this just for the first time a prompt is shown? I still see a slight lag the first time a prompt is opened, but further prompts open instantly. Seems ok on both Windows and OS X. How about we open a bug specifically about the perf issue? I think we want to take this patch -- ideally for beta 8 -- even if it's not helping that (ie, perf wasn't the only reason for removing the blur).

(In reply to comment #44) > Is this just for the first time a prompt is shown? I still see a slight lag the > first time a prompt is opened, but further prompts open instantly. Seems ok on > both Windows and OS X. For me, typing the following into the addressbar creates a ~1 second lag before the prompt shows up, every time I load it: javascript: alert(""); > How about we open a bug specifically about the perf issue? I think we want to > take this patch -- ideally for beta 8 -- even if it's not helping that (ie, > perf wasn't the only reason for removing the blur). Yeah, this patch is better than blur AND desaturate for usability. Bug 614810 was originally about the responsiveness of the tab-modal prompts, but was duped here. Maybe reopen/de-dupe it to investigate the perf issue there?

(In reply to comment #44) > Is this just for the first time a prompt is shown? I still see a slight lag the > first time a prompt is opened, but further prompts open instantly. Seems ok on > both Windows and OS X. All the time, on Windows and Linux. I just measured it on Linux using the error console: var w = top.opener; var b = w.gBrowser; var c = w.content; w.t = Date.now(); w.addEventListener("MozAfterPaint", function (e) { var w = e.currentTarget; w.removeEventListener("MozAfterPaint", arguments.callee, false); w.Components.utils.reportError((Date.now() - w.t) / 1000); }, false); void(c.location = "javascript:alert('1')"); With the blur, it takes about 0.8 seconds, about 0.54 with the desaturation. With the desaturation removed, it drops to about 0.24 seconds, which leaves room for improvement but might be acceptable. > How about we open a bug specifically about the perf issue? I think we want to > take this patch -- ideally for beta 8 -- even if it's not helping that (ie, > perf wasn't the only reason for removing the blur). I don't see us solving the perf issue while maintaining the proposed styling, so I'd rather we tackled it together.

Comment on attachment 494282 [details] [diff] [review] Patch v.1 I don't think the desaturation adds much to the effect, so r=me with the filter and effects.svg removed.

I think the effect is important; we'll likely want to replace it with a semitransparent gray (?) overlay to get something vaguely similar. But I'd like to go ahead and land this as-is; looks like beta 8 freeze is very close and this patch fixes the primary goal here without making anything worse. I definitely will investigate the perf issue next, not going to just drop that on the floor. :)

So just file a bug on adding a semitransparent gray overlay? The svg effect needs to go away.

(In reply to comment #46) > I don't see us solving the perf issue while maintaining the proposed styling, > so I'd rather we tackled it together. For me, the perf issue is only when using DirectWrite. Change gfx.direct2d.disabled to true and you will see the perf issue goes away entirely. It's like night and day.

(In reply to comment #50) > (In reply to comment #46) > > I don't see us solving the perf issue while maintaining the proposed styling, > > so I'd rather we tackled it together. > > For me, the perf issue is only when using DirectWrite. Change > gfx.direct2d.disabled to true and you will see the perf issue goes away > entirely. It's like night and day. While it's possible that a direct2d bug makes this even worse, it wasn't involved at all when I tested this on XP and Linux.

(In reply to comment #49) > So just file a bug on adding a semitransparent gray overlay? The svg effect > needs to go away. I don't understand why you think that has to be done in this bug. We have a design, a patch, and can handle the rest in a followup.

Design-conformance isn't the only criterion. The patch at hand has a performance problem. The cause has been identified and unless there's a very good reason for keeping it around, spending time on tweaking it and exposing it to users, it should be eliminated asap. We usually don't postpone bug fixes just because it's technically possible.

Giving this another try on a more colorful page

So it still seems to me that the desaturation isn't critical. Nice: yes. Really needed to let the alert stand out: no. We should land this without it and then explore ways to further tweak the styling without regressing UI responsiveness.

Also, shouldn't the alert itself be bolder somehow (including adding conventional colors to the alert icon types)? It's pretty weak as is, and I wouldn't blame anyone for missing it.

(In reply to comment #58) > Also, shouldn't the alert itself be bolder somehow (including adding > conventional colors to the alert icon types)? It's pretty weak as is, and I > wouldn't blame anyone for missing it. I guess I am not alone in thinking these prompts just don't stand out as it seems they should. The "old" way with title bar and all seem to stand out as tab modal prompts should. So long as we have a choice between the two, I'll stay with the current setup.

>shouldn't the alert itself be bolder somehow (including adding >conventional colors to the alert icon types)? It's pretty weak as is, and I >wouldn't blame anyone for missing it. As usual these were designed as a whole (the light apperance works well when you do something else to draw attention to it). The lack of color is so that these will work ok when presented along with a wide range of designs in the content area. Also, they are not meant to appear to be coming from the system or the browser.

Patch with effects.svg removed to ensure this makes Beta 8.

Pushed http://hg.mozilla.org/mozilla-central/rev/99cdd78edfe4

I take it the patch effectively created a non see-though background without the svg. :-/

What I see is a completely blocking radial gradient BG, on WINXP, like this: http://img535.imageshack.us/img535/8103/dimmed.png Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101213 Firefox/4.0b8pre

Filed: Bug 619057 - Tab modal prompts hide the whole website

I definitely am not an expert at this, but it seems that this change is wrong: http://hg.mozilla.org/mozilla-central/diff/99cdd78edfe4/browser/themes/winstripe/browser/browser.css It refers to a .svg file that has been removed. Dropping that line of css fixes the effect and gets the desired result... If I read it all correctly it was done right for Mac and Linux, but forgotten on Windows...

when a prompt appears on a web site, there is no warning on taskbar if that window is minimized before. There has to be a flashing warning that page says something. Am i wrong? My os: Windows 7 64bit

This is 1000% better than before (I realize that this is not possible). This is especially better on Yahoo! mail where you used to got prompts like "Are you sure you want to delete all of these emails" when you had no idea what emails it was referring to because they were impossible to see due to the blurring.

(In reply to comment #67) > when a prompt appears on a web site, there is no warning on taskbar if that > window is minimized before. There has to be a flashing warning that page says > something. Thats for bug 598824. This bug is only about adjusting being able to see the webpage behind a prompt that is shown instead of the blur.

I DESPISE this attention getting ploy. I find it totally distracting and one of the stylistic flaws in FF. I very much prefer that the alert pop up NOT make ANY style changes to the main screen the same way that most other browsers do. I have pretty severe vision issues and this feature makes it extremely difficult to use FF at ant point that an alert is on screen. Please either take the attention getting feature off completely (we aren't so dumb as users that we can't tell there is an alert in screen) or at the very least add a parameter to about:config to allow users to disable it. This is one of the worst design elements in all of FF. The user mentioning yahoo mail above is a prime example of when this feature is 100% annoying.