Closed Bug 677095 Opened 13 years ago Closed 13 years ago

1px background-image mishandled when position is fixed

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla8
Tracking Flags:
Tracking Status
firefox6 + wontfix
firefox7 + wontfix

People

(Reporter: mail, Assigned: roc)

References

Details

(Keywords: qawanted, regression)

Attachments

(5 files, 1 obsolete file)

screen shot
10.88 KB, image/png
Details
Screenshot_of_the_issue_Win7
105.62 KB, image/png
Details
showcase.html
835 bytes, text/html
Details
Screenshot from Alienware Machine
77.10 KB, image/png
Details
fix underlying bug
536.01 KB, patch
bas.schouten
: review+
christian
: approval-mozilla-beta-
Details | Diff | Splinter Review
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....
tracking-firefox6: --- → ?
tracking-firefox7: --- → ?
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.

Attachment

General

Creator:
Created:
Updated:
Size: