Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Reporter
	Description • 14 years ago

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

	gadjo
	Comment 2 • 14 years ago

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")

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Reporter
	Comment 3 • 14 years ago

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.

	Jim Jeffery not reading bug-mail 1/2/11
	Comment 4 • 14 years ago

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

	gadjo
	Comment 5 • 14 years ago

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

	kuvik3
	Comment 6 • 14 years ago

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

	[not reading bugmail]
	Comment 7 • 14 years ago

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.

	Nikita Popov
	Comment 8 • 14 years ago

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.

	Zéfling
	Comment 9 • 14 years ago

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

	(account disabled for personal attacks)
	Comment 10 • 14 years ago

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.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Reporter
	Comment 11 • 14 years ago

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.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Reporter
	Comment 12 • 14 years ago

And what that patch looks like.

	(account disabled for personal attacks)
	Comment 13 • 14 years ago

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

	gadjo
	Comment 14 • 14 years ago

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

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Reporter
	Comment 15 • 14 years ago

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?)

	Roman
	Comment 16 • 14 years ago

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

	Siddhartha Dugar [:sdrocking]
	Comment 17 • 14 years ago

This should be fixed before beta 8.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Reporter
	Comment 18 • 14 years ago

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.

	Nikita Popov
	Comment 19 • 14 years ago

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

	StyleThing
	Comment 20 • 14 years ago

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

	Nikita Popov
	Comment 21 • 14 years ago

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!

	[not reading bugmail]
	Comment 22 • 14 years ago

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.

	Csaba Kozák [:WonderCsabo]
	Comment 23 • 14 years ago

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

	David Balažic
	Comment 24 • 14 years ago

(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?)

	[Baboo]
	Comment 25 • 14 years ago

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

	Ralph
	Comment 27 • 14 years ago

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.

	Nikita Popov
	Comment 28 • 14 years ago

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

	Jase Zhang
	Comment 29 • 14 years ago

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

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 31 • 14 years ago

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

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Reporter
	Comment 32 • 14 years ago

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.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Reporter
	Comment 33 • 14 years ago

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.

	gadjo
	Comment 34 • 14 years ago

Bug 613754 refers to the prompt opacity

	Justin Dolske [:Dolske] Assignee
	Comment 35 • 14 years ago

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.

	Justin Dolske [:Dolske] Assignee
	Comment 37 • 14 years ago

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! :)

	Dão Gottwald [:dao]
	Comment 38 • 14 years ago

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.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Reporter
	Comment 39 • 14 years ago

(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?)

	Dave Garrett
	Comment 40 • 14 years ago

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?)

	David Baron :dbaron:
	Comment 41 • 14 years ago

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.

	IU
	Comment 42 • 14 years ago

Would fixing bug 595671 help here?

	Deniz Sarikaya
	Comment 43 • 14 years ago

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. :(

	Justin Dolske [:Dolske] Assignee
	Comment 44 • 14 years ago

(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).

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed) Reporter
	Comment 45 • 14 years ago

(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?

	Dão Gottwald [:dao]
	Comment 46 • 14 years ago

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

	Dão Gottwald [:dao]
	Comment 47 • 14 years ago

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.

	Justin Dolske [:Dolske] Assignee
	Comment 48 • 14 years ago

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. :)

	Dão Gottwald [:dao]
	Comment 49 • 14 years ago

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

	Nochum Sossonko [:Natch]
	Comment 50 • 14 years ago

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

	Dão Gottwald [:dao]
	Comment 51 • 14 years ago

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

	Justin Dolske [:Dolske] Assignee
	Comment 52 • 14 years ago

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

	Dão Gottwald [:dao]
	Comment 53 • 14 years ago

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.

	Dão Gottwald [:dao]
	Comment 54 • 14 years ago

Giving this another try on a more colorful page

	Dão Gottwald [:dao]
	Comment 57 • 14 years ago

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.

	IU
	Comment 58 • 14 years ago

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.

	WildcatRay
	Comment 59 • 14 years ago

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

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 60 • 14 years ago

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

	Justin Dolske [:Dolske] Assignee
	Comment 61 • 14 years ago

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

	Justin Dolske [:Dolske] Assignee
	Comment 62 • 14 years ago

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

	[not reading bugmail]
	Comment 63 • 14 years ago

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

	Kemcy BEST
	Comment 64 • 14 years ago

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

	JK
	Comment 65 • 14 years ago

Filed:

Bug 619057 - Tab modal prompts hide the whole website

	pino_sb
	Comment 66 • 14 years ago

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

	Can
	Comment 67 • 14 years ago

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

	Bill Gianopoulos [:WG9s]
	Comment 68 • 14 years ago

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.

	[not reading bugmail]
	Comment 69 • 14 years ago

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

	DavidB
	Comment 71 • 13 years ago

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.