Closed Bug 677095 Opened 13 years ago Closed 13 years ago

1px background-image mishandled when position is fixed

Categories

(Core :: Layout, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla8
Tracking Status
firefox6 + wontfix
firefox7 + wontfix

People

(Reporter: mail, Assigned: roc)

References

Details

(Keywords: qawanted, regression)

Attachments

(5 files, 1 obsolete file)

Attached file showcase.html (obsolete) —
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110807 Firefox/7.0a2
Build ID: 20110807042007

Steps to reproduce:

1. Get the attached html file.
2. Load that file into Firefox.

Remark: That file uses two image files from a site of mine.


Actual results:

You can see one white line above the background-image at the top.


Expected results:

You should not see it.
Tested to work in FF5, FF6, IE, Chrome and Opera.
Just to make sure: This happens with my current profile AND with new profiles.

There are some ways to get that line away:
Either by removing the background-color from the top element
or by setting the width of the top element to something lower than 100%.
Removing the bottom element fixes the problem, too.
Attachment #551323 - Attachment mime type: text/plain → text/html; charset=UTF-8
I could reproduce the issue also on the latest Firefox Nightly (Windows 7)
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:8.0a1) Gecko/20110807 Firefox/8.0a1

There is a white line at the top when loading the html testcase attached.
If not a dupe this bug may be set as NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This worksforme on Mac....

Lars, AndreiD, since you can reproduce, would you mind figuring out when this behavior changed using http://harthur.github.com/mozregression/ ?
(In reply to Boris Zbarsky (:bz) from comment #3)
> This worksforme on Mac....
> 
> Lars, AndreiD, since you can reproduce, would you mind figuring out when
> this behavior changed using http://harthur.github.com/mozregression/ ?

Boris, I did a regression using harthur's tool and got the following result on Win7

Last good nightly: 2011-05-13
First bad nightly: 2011-05-14

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ad1fa68dcaf5&tochange=8404426ef391
AndreiD, thanks!

Jim, this looks like a likely regression from bug 633282 to me, given that range.

Requesting tracking for this regression.  Chances are, it's too late for Fx6, sadly.  :(

What's interesting is that AndreiD sees this in nightlies that became Fx6, but Lars doesn't seem to see it on the beta channel....
Keywords: regression
Version: 7 Branch → Trunk
Blocks: 633282
(In reply to Boris Zbarsky (:bz) from comment #5)
> AndreiD, thanks!
I'm glad I could help

> What's interesting is that AndreiD sees this in nightlies that became Fx6, but 
> Lars doesn't seem to see it on the beta channel....

I don't know about Lars, but I can see the issue on the latest Beta and Aurora, as well, Win7:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a2) Gecko/20110808 Firefox/7.0a2
Attached image screen shot
What am I looking for here? I see a gray border but no white line around content. Maybe I'm looking in the wrong place?
There is a white line - 1px height, at the top of the webpage content (the html test file attached)
(In reply to AndreiD from comment #8)
> Created attachment 551749 [details]
> Screenshot_of_the_issue_Win7
> 
> There is a white line - 1px height, at the top of the webpage content (the
> html test file attached)

Odd, I see it in your screen shot but am not able to reproduce locally. 

1) maximized window
2) tabs on top
3) navigation bar visible, all other toolbars hidden
4) menubar displayed

Is there anything (like an add-on or other customization) you can think of that makes your situation unique?
Keywords: qawanted
> Is there anything (like an add-on or other customization) you can think of
> that makes your situation unique?

I'm sorry, no :)
I'm on a clean profile with no addons and the standard Fx first run settings.
Could it be something related to the system's graphics component?
(In reply to AndreiD from comment #10)
> > Is there anything (like an add-on or other customization) you can think of
> > that makes your situation unique?
> 
> I'm sorry, no :)
> I'm on a clean profile with no addons and the standard Fx first run settings.
> Could it be something related to the system's graphics component?

Does this happen in a normalized window? Also, have you customized any system settings like border padding on windows?
> Does this happen in a normalized window? Also, have you customized any
> system settings like border padding on windows?

On the system side, the settings are the standard ones. 
I see the white line in a normalized window (regardless the size).
I don't see it in Fullscreen mode, though.
> Does this happen in a normalized window? Also, have you customized any
> system settings like border padding on windows?

I switched to an onboard graphics card (Intel G41 Express) and I cannot reproduce the issue anymore on Win 7, neither x86 or x64:
Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0

Also I could not reproduce the issue on the following systems:
Win XP: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20100101 Firefox/6.0
Mac OS 10.6: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20100101 Firefox/6.0
Ubuntu 11.04: Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20100101 Firefox/6.0

So, it seems that the graphics card or its drivers were the issue:
ATI Radeon HD4300 Series;

In my opinion further investigation is needed, which would not leave room for this bug to track firefox 6. Thanks!
AndreiD, can you attach your output from about:support? (click "copy all to clipboard"). Thanks!
I don't think we've run into a case where glass calculations are buggy based on the video driver. If that is the cause though I'd expect similar anomalies in other applications that rely on custom glass settings.
In that range http://hg.mozilla.org/mozilla-central/rev/12d72a30fe94 looks pretty suspect to my untrained eye...though if Jim didn't jump on that change as well I am probably wrong :-)
(In reply to Christian Legnitto [:LegNeato] from comment #16)
> In that range http://hg.mozilla.org/mozilla-central/rev/12d72a30fe94 looks
> pretty suspect to my untrained eye...though if Jim didn't jump on that
> change as well I am probably wrong :-)

We changed the way we calculate glass margins in bug 633282 to an opt-in type system that changed where the glass borders are placed. (They are more exact in terms of delineating content vs. chrome.) The issue here seems to be that the separation point is rendered correctly on most systems but isn't rendered properly on AndreiD's system with a particular driver. Which is odd to say the least. The values calculated appear to be correct unless our calculations are being affected by drivers, which isn't likely.

One possible source of this anomaly is this line: 

largest.y = PR_MAX(largest.y,
 nsUXThemeData::sCommandButtons[CMDBUTTONIDX_BUTTONBOX].cy);

which is why I asked about custom UI settings. But since it works fine with one driver and is broken with another I think we can rule this out.
(In reply to Jim Mathies [:jimm] from comment #17)
> (In reply to Christian Legnitto [:LegNeato] from comment #16)
> > In that range http://hg.mozilla.org/mozilla-central/rev/12d72a30fe94 looks
> > pretty suspect to my untrained eye...though if Jim didn't jump on that
> > change as well I am probably wrong :-)
> 
> We changed the way we calculate glass margins in bug 633282 to an opt-in
> type system that changed where the glass borders are placed. (They are more
> exact in terms of delineating content vs. chrome.) The issue here seems to
> be that the separation point is rendered correctly on most systems but isn't
> rendered properly on AndreiD's system with a particular driver. Which is odd
> to say the least. The values calculated appear to be correct unless our
> calculations are being affected by drivers, which isn't likely.
> 
> One possible source of this anomaly is this line: 
> 
> largest.y = PR_MAX(largest.y,
>  nsUXThemeData::sCommandButtons[CMDBUTTONIDX_BUTTONBOX].cy);
> 
> which is why I asked about custom UI settings. But since it works fine with
> one driver and is broken with another I think we can rule this out.

Also, even if there were a bug there, a white line showing up where the glass ends doesn't make a lot of sense. We've seen this with child windows of plugins, but never in the content we render.
Sorry for the long delay, I just encountered this bug while working and wanted to make sure you at least know of it even when I've not enough time for testing.

* Sorry for the wrong information about FF6. It does not work for me, too. It seems I just used the wrong folder while testing...
* Changing from Aero to the Basic theme fixes the issue.
* Disabling hardware-rendering (while keeping Aero activated) helps, too.

Shall we really put our info in here or better via pastebin? Well, here it is:


  Allgemeine Informationen

        Name
        Firefox

        Version
        7.0a2

        User-Agent
        Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110809 Firefox/7.0a2

        Profilordner

          Beinhaltenden Ordner anzeigen

        Aktivierte Plugins

          about:plugins

        Build-Konfiguration

          about:buildconfig

  Erweiterungen

        Name

        Version

        Aktiviert

        ID

        Add-on Compatibility Reporter
        0.8.7
        true
        compatibility@addons.mozilla.org

        Deutsches Wörterbuch
        2.0.2
        true
        de-DE@dictionaries.addons.mozilla.org

        Download Statusbar
        0.9.8
        true
        {D4DD63FA-01E4-46a7-B6B1-EDAB7D6AD389}

        Firebug
        1.8.0b6
        true
        firebug@software.joehewitt.com

        FireFTP
        1.99.5
        true
        {a7c6cf7f-112c-4500-a7ea-39801a327e5f}

        Fox!Box
        1.2.0
        true
        {df4e4df5-5cb7-46b0-9aef-6c784c3249f8}

        Nokia Drop
        1.1.0.10621
        true
        {12c86d9f-4404-481a-9353-7d1015ddeac4}

        Tab Mix Plus
        0.3.8.6pre.110303a
        true
        {dc572301-7619-498c-a57d-39143191b318}

        Telekom YouTube Turbo
        1.0.1
        true
        info@maltegoetz.de

        United States English Spellchecker
        5.0.1
        true
        en-US@dictionaries.addons.mozilla.org

        Firefox Synchronisation Extension
        7.3.4.76
        false
        {A27F3FEF-1113-4cfb-A032-8E12D7D8EE70}

        FireSSH
        0.87
        false
        firessh@nightlight.ws

        Free YouTube Download (Free Studio) Menu
        1.0.4
        false
        {ACAA314B-EEBA-48e4-AD47-84E31C44796C}

        Java Console
        6.0.25
        false
        {CAFEEFAC-0016-0000-0025-ABCDEFFEDCBA}

  Modifizierte Einstellungen

      Name

      Wert

        accessibility.typeaheadfind.flashBar
        0

        browser.places.smartBookmarksVersion
        2

        browser.startup.homepage
        about:blank

        browser.startup.homepage_override.buildID
        20110809042012

        browser.startup.homepage_override.mstone
        rv:7.0a2

        browser.tabs.closeWindowWithLastTab
        false

        browser.tabs.loadFolderAndReplace
        false

        browser.tabs.warnOnClose
        false

        extensions.checkCompatibility
        false

        extensions.checkCompatibility.3.6
        false

        extensions.checkCompatibility.3.6.previous
        false

        extensions.checkCompatibility.3.6b
        false

        extensions.checkCompatibility.3.6b.previous
        false

        extensions.checkCompatibility.3.6p
        false

        extensions.checkCompatibility.3.6p.previous
        false

        extensions.checkCompatibility.3.6pre
        false

        extensions.checkCompatibility.3.6pre.previous
        false

        extensions.checkCompatibility.3.7a
        false

        extensions.checkCompatibility.3.7a.previous
        false

        extensions.checkCompatibility.4.0
        false

        extensions.checkCompatibility.4.0.previous
        false

        extensions.checkCompatibility.4.0b
        false

        extensions.checkCompatibility.4.0b.previous
        false

        extensions.checkCompatibility.4.0p
        false

        extensions.checkCompatibility.4.0p.previous
        false

        extensions.checkCompatibility.4.0pre
        false

        extensions.checkCompatibility.4.0pre.previous
        false

        extensions.checkCompatibility.4.2
        false

        extensions.checkCompatibility.4.2.previous
        false

        extensions.checkCompatibility.4.2a
        false

        extensions.checkCompatibility.4.2a.previous
        false

        extensions.checkCompatibility.4.2b
        false

        extensions.checkCompatibility.4.2b.previous
        false

        extensions.checkCompatibility.4.2p
        false

        extensions.checkCompatibility.4.2p.previous
        false

        extensions.checkCompatibility.4.2pre
        false

        extensions.checkCompatibility.4.2pre.previous
        false

        extensions.checkCompatibility.5.0
        false

        extensions.checkCompatibility.5.0.previous
        false

        extensions.checkCompatibility.5.0a
        false

        extensions.checkCompatibility.5.0a.previous
        false

        extensions.checkCompatibility.5.0b
        false

        extensions.checkCompatibility.5.0b.previous
        false

        extensions.checkCompatibility.5.0p
        false

        extensions.checkCompatibility.5.0p.previous
        false

        extensions.checkCompatibility.5.0pre
        false

        extensions.checkCompatibility.5.0pre.previous
        false

        extensions.checkCompatibility.6.0
        false

        extensions.checkCompatibility.6.0.previous
        false

        extensions.checkCompatibility.6.0a
        false

        extensions.checkCompatibility.6.0a.previous
        false

        extensions.checkCompatibility.7.0
        false

        extensions.checkCompatibility.7.0.previous
        false

        extensions.checkCompatibility.7.0a
        false

        extensions.checkCompatibility.7.0a.previous
        false

        extensions.checkCompatibility.8.0
        false

        extensions.checkCompatibility.8.0.previous
        false

        extensions.checkCompatibility.8.0a
        false

        extensions.checkCompatibility.8.0a.previous
        false

        extensions.checkCompatibility.nightly
        false

        extensions.checkCompatibility.nightly.previous
        false

        extensions.checkCompatibility.previous
        false

        extensions.lastAppVersion
        7.0a2

        network.cookie.prefsMigrated
        true

        places.database.lastMaintenance
        1312904778

        places.history.expiration.transient_current_max_pages
        64406

        privacy.cpd.extensions-tabmix
        true

        privacy.cpd.siteSettings
        true

        privacy.donottrackheader.enabled
        true

        privacy.sanitize.migrateFx3Prefs
        true

        privacy.sanitize.timeSpan
        0

        security.warn_viewing_mixed
        false

  Grafik

        Karten-Beschreibung
        NVIDIA GeForce 8600 GTS

        Vendor-ID
        10de

        Geräte-ID
        0400

        Karten-Ram
        256

        Karten-Treiber
        nvd3dum nvwgf2um,nvwgf2um

        Treiber-Version
        8.17.12.7533

        Treiber-Datum
        5-20-2011

        Direct2D aktiviert
        true

        DirectWrite aktiviert
        true (6.1.7601.17563)

        ClearType-Parameter
        ClearType-Parameter nicht gefunden

        WebGL-Renderer
        Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.686)

        GPU-beschleunigte Fenster
        1/1 Direct3D 10
> * Sorry for the wrong information about FF6. It does not work for me, too.

Lars, did you remove the png file from the server? 
Here should be the orange background: http://media23.de/get/template/bottom.png, as in the source of the html test file.

This thing deceived me and I could not see the white line. But it's still there.
Steps to reproduce:
1. Open the testcase https://bugzilla.mozilla.org/attachment.cgi?id=551323
2. Mouse select the word "top"

In step 2 notice a white line at the top of the selected word (1 px height)

I could reproduce this on the following machine:

  Application Basics
        Name
        Firefox
        Version
        6.0
        User Agent
        Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
        Profile Directory
          Open Containing Folder
        Enabled Plugins
          about:plugins
        Build Configuration
          about:buildconfig

  Extensions
        Name
        Version
        Enabled
        ID
        Feedback
        1.1.2
        true
        testpilot@labs.mozilla.com
        RealPlayer Browser Record Plugin
        14.0.1
        false
        {ABDE892B-13A8-4d1b-88E6-365A6E755758}

  Modified Preferences
      Name
      Value
        browser.places.smartBookmarksVersion
        2
        browser.startup.homepage_override.buildID
        20110804030150
        browser.startup.homepage_override.mstone
        rv:6.0
        extensions.lastAppVersion
        6.0
        network.cookie.prefsMigrated
        true
        places.history.expiration.transient_current_max_pages
        96323
        privacy.sanitize.migrateFx3Prefs
        true
        security.warn_viewing_mixed
        false
  Graphics
        Adapter Description
        Mobile Intel(R) 965 Express Chipset Family
        Vendor ID
        8086
        Device ID
        2a02
        Adapter RAM
        Unknown
        Adapter Drivers
        igdumd64 igd10umd64 igdumdx32 igd10umd32
        Driver Version
        8.15.10.1930
        Driver Date
        9-23-2009
        Direct2D Enabled
        Blocked for your graphics driver version.
        DirectWrite Enabled
        false (6.1.7601.17563)
        ClearType Parameters
        ClearType parameters not found
        WebGL Renderer
        Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.686)
        GPU Accelerated Windows
        1/1 Direct3D 9
Hmpf, am sorry... the correct url is http://media23.de/get/bottom.png now.
Attached file showcase.html
Revised test case to use new image URLs as indicated in comment 21.
Attachment #551323 - Attachment is obsolete: true
I don't see this with Firefox 6.0b5 in a Windows 7 Ultimate VM. I'm guessing, based on this fact and previous comments, this MIGHT be related to certain video drivers.
I don't see the issue on Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20100101 Firefox/6.0
Lars, thanks for the follow up. 

>* Disabling hardware-rendering (while keeping Aero activated) helps, too.

By "helps" do you mean the white line is gone, or something else?

To summarize: this is reproducible on 

Firefox/8.0a1
Firefox/7.0a2
Firefox/6.0

but not 5.0.
> By "helps" do you mean the white line is gone, or something else?

Exactly that.
(In reply to Lars Knickrehm from comment #26)
> > By "helps" do you mean the white line is gone, or something else?
> 
> Exactly that.

Would you mind trying something for me?

1) enabled acceleration via the options panel
2) in about:config, make sure 'gfx.direct2d.disabled' is false, and set 'layers.acceleration.disabled' to true.
3) restart, and see if you still see the problem.

With this config, the gfx section in about:support should show: 

Direct2D aktiviert
true

GPU-beschleunigte Fenster
0/1
I can reproduce this in the lab using the Firefox 6 Beta 5 candidate. If I turn off hardware acceleration the 1 pixel issue goes away. Machine specs:

  Application Basics

        Name
        Firefox

        Version
        6.0

        User Agent
        Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0

        Profile Directory

          Open Containing Folder

        Enabled Plugins

          about:plugins

        Build Configuration

          about:buildconfig

  Extensions

        Name

        Version

        Enabled

        ID

        Feedback
        1.1.2
        true
        testpilot@labs.mozilla.com

        DivX HiQ
        2.1.0.900
        false
        {6904342A-8307-11DF-A508-4AE2DFD72085}

        DivX Plus Web Player HTML5 <video>
        2.1.0.900
        false
        {23fcfd51-4958-4f00-80a3-ae97e717ed8b}

        McAfee SiteAdvisor
        3.3.1
        false
        {B7082FAA-CB62-4872-9106-E42DD88EDE45}

  Modified Preferences

      Name

      Value

        browser.places.smartBookmarksVersion
        2

        browser.startup.homepage_override.buildID
        20110804030150

        browser.startup.homepage_override.mstone
        rv:6.0

        extensions.lastAppVersion
        6.0

        network.cookie.prefsMigrated
        true

        places.history.expiration.transient_current_max_pages
        386470

        privacy.sanitize.migrateFx3Prefs
        true

        security.warn_viewing_mixed
        false

  Graphics

        Adapter Description
        NVIDIA Quadro NVS 295

        Vendor ID
        10de

        Device ID
        06fd

        Adapter RAM
        256

        Adapter Drivers
        nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um

        Driver Version
        8.17.12.7533

        Driver Date
        5-20-2011

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17563)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.686)

        GPU Accelerated Windows
        1/1 Direct3D 10
If I follow these steps on my machine I do not see the 1 pixel issue.

(In reply to Jim Mathies [:jimm] from comment #27)
> (In reply to Lars Knickrehm from comment #26)
> > > By "helps" do you mean the white line is gone, or something else?
> > 
> > Exactly that.
> 
> Would you mind trying something for me?
> 
> 1) enabled acceleration via the options panel
> 2) in about:config, make sure 'gfx.direct2d.disabled' is false, and set
> 'layers.acceleration.disabled' to true.
> 3) restart, and see if you still see the problem.
> 
> With this config, the gfx section in about:support should show: 
> 
> Direct2D aktiviert
> true
> 
> GPU-beschleunigte Fenster
> 0/1
(In reply to Jim Mathies [:jimm] from comment #27)
> (In reply to Lars Knickrehm from comment #26)
> > > By "helps" do you mean the white line is gone, or something else?
> > 
> > Exactly that.
> 
> Would you mind trying something for me?
> 
> 1) enabled acceleration via the options panel
> 2) in about:config, make sure 'gfx.direct2d.disabled' is false, and set
> 'layers.acceleration.disabled' to true.
> 3) restart, and see if you still see the problem.
> 
> With this config, the gfx section in about:support should show: 
> 
> Direct2D aktiviert
> true
> 
> GPU-beschleunigte Fenster
> 0/1

You are absolutely right. I can confirm that.
My Alienware machine shows the issue as well when running FF 6 Beta 5. The pixel issue is a bit is a bit sloppier on this machine when the issue happens. Will attach a screenshot shortly.

  Graphics

        Adapter Description
        Intel(R) HD Graphics

        Vendor ID
        8086

        Device ID
        0046

        Adapter RAM
        Unknown

        Adapter Drivers
        igdumd64 igd10umd64 igdumdx32 igd10umd32

        Driver Version
        8.15.10.2226

        Driver Date
        10-15-2010

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17563)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Blocked for your graphics card because of unresolved driver issues.

        GPU Accelerated Windows
        1/1 Direct3D 10
Marcia, I'm curious if your drivers are the latest provided via Windows Update?
If we can't figure out a driver version to blacklist, or it's too popular to blacklist, and we have no traction on the underlying bug (which does feel like a Windows or driver bug to me), we could try to make the -moz-win-exclude-glass element is one pixel taller than the content window and see if that fixes it.
Actually I can reproduce this! Investigating!
Screenshot from Alienware machine using NVIDIA 8.17.12.6099 driver. This driver is not up to date as a new version was released yesterday.
Updating to the latest NVIDIA driver on the Alienware Laptop (8.17.12.8026) does not resolve the pixel issue for me in Firefox 6 Beta 5.
I think the root cause is some kind of bug in D3D10 component alpha layer rendering, probably triggered by having multiple rects in the visible region:
-- If you take the text out of the testcase, so the layer is no longer component-alpha, the bug goes away.
-- If you modify the testcase so that there is only one rectangle in the layer's visible region, the bug goes away.

Having multiple rects in the layer visible region is relatively rare, which is perhaps why we don't see this bug much.

If you look carefully, the "white" lines are actually dependent on what's under the window. This kind of bug --- where the DWM composites our window in a weird way --- also shows up when we have a windowed plugin visible next to the glass boundary. Maybe it could be triggered by D3D buffer pixels that have color channel values larger than the alpha value? I can't think of anything else that could be wrong with the buffer values.

Modifying ThebesLayerD3D10::RenderLayer to render the entire layer with one rectangle draw doesn't fix it.

I haven't been able to track it down any further yet. I'll keep looking into it, but I probably won't be able to fix it today.

I think we can back out bug 633282 if we need to to get Firefox 6 out the door. The only reason not to do that would be if we decide bug 633282 is worse than this bug.
The problem is that ComponentAlphaBlend currently preserves the destination alpha value unchanged. Normally this is OK because component alpha blending usually blends to a destination that is already opaque (we tend to disable component alpha blending over transparent parts of a window). In this testcase, because we know part of the content in the component-alpha layer is actually opaque, we've done some optimizations and not actually drawn anything into the window buffer under the top DIV before we composite the component alpha layer. So, that composite operation leaves the alpha value in the window buffer at zero. This is obviously a bad idea.

This patch fixes it by picking one of the channel alphas (the green channel) to use as an alpha value for the entire pixel, and combining that with the destination alpha in the usual way. This matches what we do in D3D9.

Because a component-alpha layer will only be allowed if we know it's over an opaque part of the window, normally the destination alpha will already be 1.0 before we composite; in rare cases (this bug's case) we have not drawn the destination pixel yet because we know the component-alpha layer (or something on top of it) will draw opaque. So it doesn't really matter what alpha we choose for our source alpha as long as, where the component-alpha layer has an opaque pixel, the source alpha computes to 1.0. Being consistent across layer backends seems good though.

It looks to me like GL needs to be fixed too. It picks the green channel to use as an alpha channel, but the alpha blend modes in ThebesLayerBufferOGL::RenderTo for component alpha are wrong. It probably doesn't matter yet for GL since we don't support window buffers with alpha yet there.
Assignee: nobody → roc
Attachment #552349 - Flags: review?(bas.schouten)
Matt, see the comment about GL above.
For release-drivers: the above patch should be low risk, but we might prefer to leave this bug unfixed for FF6. The combination of circumstances that triggers it seems quite rare (D3D10 enabled, plus a particular content setup that seems rare), and the effects are mild. I think it's less severe than the effects of bug 633282.
If of any help, here are the results for the tests I did to reproduce the issue considering different driver versions:

Firefox build: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0
-> clean install / new profile

INTEL (G41 Express Edition):
-> WFM:          driver version 8.15.10.1883 / 8/27/2009
-> Reproducible: driver version 8.15.10.2413 / 6/3/2011
-> Reproducible: driver version 8.15.10.2302 / 2/11/2011

AMD (Radeon HD 4300 Series)
-> Reproducible: driver version 8.872.0.0 / 7/7/2011
Roc: thanks so much for the analysis! I think we'll live with this for 6 as you suggest.
(In reply to Christian Legnitto [:LegNeato] from comment #42)
> Roc: thanks so much for the analysis! I think we'll live with this for 6 as
> you suggest.

Should we consider pushing this to Aurora as well? 8 isn't scheduled to go out until mid-November.
> The combination of circumstances that triggers it seems quite rare (D3D10 enabled, plus a particular content setup that seems rare)

In general you're right, but (I guess) D3D10 is enabled on most Windows Vista / 7 systems, isn't it?

Additionally this is "just" a rendering bug and does not change the calculated values specified by the site, so it does not effect the rest of the layout.

PS: Do you have any small html / css fix for FF6 to work around this?
(In reply to Jim Mathies [:jimm] from comment #43)
> (In reply to Christian Legnitto [:LegNeato] from comment #42)
> > Roc: thanks so much for the analysis! I think we'll live with this for 6 as
> > you suggest.
> 
> Should we consider pushing this to Aurora as well? 8 isn't scheduled to go
> out until mid-November.

We'd definitely consider for Aurora once the patch is reviewed
Comment on attachment 552349 [details] [diff] [review]
fix underlying bug

Yep, this is the right fix if we can be blending to non-opaque areas.
Attachment #552349 - Flags: review?(bas.schouten) → review+
(In reply to Lars Knickrehm from comment #44)
> PS: Do you have any small html / css fix for FF6 to work around this?

You could make your element slightly transparent (opacity:0.999) or something like that. However, it would be better if you just don't work around it. It'll go away in six weeks, assuming we land this on Aurora.
Summary: 1px background-image miss-handling when position is fixed. → 1px background-image mishandled when position is fixed
Attachment #552349 - Flags: approval-mozilla-aurora?
(In reply to comment #47)
Using "opacity: 0.9999999;" seems to be the best workaround. Firebug shows this as "opacity: 1;" and the layer gets rendered correctly.

I don't like to put that, but I cannot sell sites showing this bug... I'll remove that code at the time Firefox 6.0 gets unsupported by Mozilla.
Or in case it's getting fixed in the stable channel...
Sorry guys, but I just noticed, that the messaging pages of Facebook have a similar bug. I'm not sure if it's the same, but it looks like.

Disabling the Layer Acceleration fixes it and setting "opacity: 0.9999999;" to the top bar fixes it, too...
https://hg.mozilla.org/mozilla-central/rev/0e37f12a6641
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla8
(In reply to Lars Knickrehm from comment #51)
> Sorry guys, but I just noticed, that the messaging pages of Facebook have a
> similar bug. I'm not sure if it's the same, but it looks like.

Can you be more specific on the url here?  I can see the issue on Aurora (but not nightly with the fix), but a quick inspection on facebook messaging doesn't show me anything.
I'm using the latest Aurora release (2011-08-15).

There's no direct link I can provide, but here are the steps you can use to provide.
1) Login to Facebook from the main page http://www.facebook.com/ .
2) Click on "Messages" in the left side bar.
3) Click on one conversation to open it.
4) Scroll the page and you'll see 1px-flickering on the top of the document.

Setting the opacity property on the element on top of the page using Firebug helps. The nightlies (which include the fix for this bug) should not show that problem.
Comment on attachment 552349 [details] [diff] [review]
fix underlying bug

Aurora [7] window has closed. Moving approval request to Beta.
Attachment #552349 - Flags: approval-mozilla-aurora? → approval-mozilla-beta?
This bug is Verified fixed on the latest Nightly as it landed on central (comment 52). 
I tested the fix on the same machine as the tests in comment 41, and it seems that the issue is not reproducible anymore on the latest Nightly.

WFM on latest Nightly: Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110818 Firefox/9.0a1
Reproducible on Aurora: Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110816 Firefox/7.0a2
Reproducible on Beta: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0
Status: RESOLVED → VERIFIED
Comment on attachment 552349 [details] [diff] [review]
fix underlying bug

We're not going to take this on beta. We shipped with this regression and have no reports of people complaining. We'll let the fix come up through the normal process.
Attachment #552349 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
Thanks for setting the "wontfix" flags. I just marked my workaround to be active for Firefox 6 and 7 only, so it can be removed some time around the 8th of November...
Blocks: 686121
Depends on: 699987
Depends on: 700050
Depends on: 701264
I'm still getting this bug in Firefox 8, but in a different way. Now this faux Aero border is popping up when a fixed positioned element has an absolutely positioned child, and is triggered by the hover event somewhere on the page.

Don't have time to put together a clean cut test demo, but it's definitely still happening in Firefox 8. It's not like my CSS code is producing this weird Aero border...
George, this should be fixed in Firefox 9.0 Beta:
http://beta.mozilla.org
You need to log in before you can comment on or make changes to this bug.