458407 - Content is blended when on top of a glass region of a window

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[sibbl]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20081003 Minefield/3.1b1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20081003 Minefield/3.1b1pre (.NET CLR 3.5.30729)

when making window background as glass the background will be glass but all black labels of the website will be glassy too (except the black labels who are on any other control, e.g. menubar, status bar, ...)

Reproducible: Always

Steps to Reproduce:
1. i add the following code to userchrome.css:

window
{background:transparent !important; -moz-appearance: -moz-win-glass !important;}

2. i start firefox and go to any website with some black elements or text
Actual Results:  
the background of the window is glass and the website, too (eg. all black colors of texts are 100% glass). Same for menu labels if the background of the menu bar is transparent. See here: http://sibbl.pytalhost.de/pix/Minefield_Start_Page_-_Minefield_472d148d5bab42dbb80fd500ef610dec.png 

Expected Results:  
the background of  the window should be glass and the website should also be completely readable. Black menu labels should also be readable when  the menu bar background is transparent.

Comment 1

[sibbl]

Attachment: sample screenshot

Comment 2

[Rob Arnold [:robarnold]]

This was a known bug when the patch for bug 418454 landed. This might depend on compositor (bug 374980) but I don't remember the exact details of why we see glass instead of black (we're painting without alpha, but it's on a child window, so...not sure why it matters too much). When bug 450767 lands, this problem should be largely mitigated as your example wouldn't have glass applied behind the content area. I wonder if painting all child windows of a glass toplevel window with alpha would work though it'd be extremely expensive; maybe there's a better solution, Vlad?

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #2)
> I wonder if painting all child windows of a glass
> toplevel window with alpha would work though it'd be extremely expensive; maybe
> there's a better solution, Vlad?

I don't know that it would be -- if we have Glass, we're on vista, so we're never getting accelerated GDI anyway; pixman is fast enough these days and can operate directly on DIBs.  So as long as text rendering doesn't slow down, it should be worth a shot...

Comment 5

[Nojevah]

I also have been concerned by this bug:
http://img149.imageshack.us/img149/2371/090508sevenfirefoxblur2.png

So, what's the status of this bug ? Are you waiting for Compositor implementation (bug 374980) ? Or a work-around can be used ?

Comment 6

[Rob Arnold [:robarnold]]

I will probably take a quick look this summer at drawing with alpha for all content on Vista/7 as a workaround. Though 7 may have GDI acceleration now so we may not want to. Vlad, have you heard anything about that?

Comment 7

[Nojevah]

I don't know if it's linked, but I think it is. If you use 
#main-window[windowtype="navigator:browser"] { background-color: transparent !important ;  } 
alone, it hides content of page whereas it should have no effect on content page.
http://img38.imageshack.us/img38/2262/transparentmainwindow.jpg (instead of showing bugzilla page, entire page is become grey)

Maybe you have decided to have an entire window transparent, but I don't see relevance in having Content transparent. So, does Content should be transparent, or not ?

Comment 8

[Rob Arnold [:robarnold]]

Attachment: Add child widget rects to opaque region

Comment 9

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Pushed http://hg.mozilla.org/mozilla-central/rev/0e62410a5e4f

Comment 10

[ronin.achilles]

(In reply to comment #8)
> Created an attachment (id=435082) [details]
> Add child widget rects to opaque region

Just tested the hourly. This seems to solve 'most' of the problems with Bug 554770. But when I played with it a little more, it seems to blur the main content area again if the Window is resized to a smaller size - not sure how to explain this. So basically I have a dual monitor set up and I use Gridmove to fix certain areas (size) on both monitors. Each area is defined by a number..say 1 to 9. Some of these areas are decently large (equal to or bigger than 1280 X 720), while some are small..(e.g. 960 X 540 px or even smaller). By pressing Win + <Num> key I can quickly cycle the Firefox window to different areas on the screen, and hence in the process change its size. When I do that... everything is fine when these 'areas' are large in size... but the moment I switch to some smaller areas on the screen, the content blur shows up. It again repairs itself, when I move to the larger area.

Comment 11

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #10)
> (In reply to comment #8)
> > Created an attachment (id=435082) [details] [details]
> > Add child widget rects to opaque region
> 
> Just tested the hourly. This seems to solve 'most' of the problems with Bug
> 554770. But when I played with it a little more, it seems to blur the main
> content area again if the Window is resized to a smaller size - not sure how to
> explain this. So basically I have a dual monitor set up and I use Gridmove to
> fix certain areas (size) on both monitors. Each area is defined by a
> number..say 1 to 9. Some of these areas are decently large (equal to or bigger
> than 1280 X 720), while some are small..(e.g. 960 X 540 px or even smaller). By
> pressing Win + <Num> key I can quickly cycle the Firefox window to different
> areas on the screen, and hence in the process change its size. When I do
> that... everything is fine when these 'areas' are large in size... but the
> moment I switch to some smaller areas on the screen, the content blur shows up.
> It again repairs itself, when I move to the larger area.

That sounds like: https://bugzilla.mozilla.org/show_bug.cgi?id=554959

Comment 12

[ronin.achilles]

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)
> > > Created an attachment (id=435082) [details] [details] [details]
> > > Add child widget rects to opaque region
> > 
> > Just tested the hourly. This seems to solve 'most' of the problems with Bug
> > 554770. But when I played with it a little more, it seems to blur the main
> > content area again if the Window is resized to a smaller size - not sure how to
> > explain this. ........
..........
> > It again repairs itself, when I move to the larger area.
> 
> That sounds like: https://bugzilla.mozilla.org/show_bug.cgi?id=554959

Note sure, coz I dont see the problem mentioned in Bug 554959 anymore, after the landing of this bug.

Comment 13

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > (In reply to comment #8)
> > > > Created an attachment (id=435082) [details] [details] [details] [details]
> > > > Add child widget rects to opaque region
> > > 
> > > Just tested the hourly. This seems to solve 'most' of the problems with Bug
> > > 554770. But when I played with it a little more, it seems to blur the main
> > > content area again if the Window is resized to a smaller size - not sure how to
> > > explain this. ........
> ..........
> > > It again repairs itself, when I move to the larger area.
> > 
> > That sounds like: https://bugzilla.mozilla.org/show_bug.cgi?id=554959
> 
> Note sure, coz I dont see the problem mentioned in Bug 554959 anymore, after
> the landing of this bug.

Indeed, does appear that this bug fixed 554959