Closed Bug 799506 Opened 12 years ago Closed 12 years ago

Images with opacity<1 and border styling sometimes not painted completely since DLBI

Categories

(Core :: Layout, defect)

18 Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox18 + fixed

People

(Reporter: me, Unassigned)

References

Details

Attachments

(3 files)

Attached file testcase (deleted) —
Attached is a very specific testcase with a lot of images that have both box-shadow and a opacity < 1 set. When force-reloading the document with ctrl-f5, you should notice that images sometimes don't get redrawn properly. The interesting part here is, that as soon as I remove one of the css properties, the images get drawn correctly everytime. I have hardware acceleration enabled, if it matters.
Blocks: dlbi
Component: Graphics → Layout
Attachment #669538 - Attachment mime type: text/plain → text/html
Few more details: I can reproduce this on almost every reload on my linux machine. On my windows machine, it happens too, but far less often. A good way I've found to trigger it on windows is to switch away from the tab for a few minutes and then activating that tab it again. Scrolling the page draws all new images that get scrolled in fine. Here's another example: 1) Go to http://catalog.neet.tv/g/ 2) Go to settings and put "img { opacity: .6;}" into the custom CSS box 3) CTRL-F5 a few times 4) Notice that some images don't get rendered at all, or stop loading halfways.
Version: 18 Branch → 19 Branch
Steps to reproduce(100% in my case) 1. Regardless HWA on/off 2. Go to http://catalog.neet.tv/g/ 3. Go to settings and put "img { opacity: .6;}" into the custom CSS box 4. Restart browser 5. Click Restore Previous Session and Do not move mouse Actual results: Images do not appear Images re-appear when mouse hover the image. Regression window Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/9f476b4ac1e1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120928040137 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/6b58397ad735 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120928042236 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9f476b4ac1e1&tochange=6b58397ad735
Status: UNCONFIRMED → NEW
Ever confirmed: true
Forgot to add, but the above link can potentially be NSFW, but it's the best example i've found so far. Attaching a screenshot of an incorrect rendering of my testcase in today's 19.0a1 nightly, which I obtained after like 50 refreshes on Windows.
Attached image incorrect rendering of testcase (deleted) —
Please ignore commnet #2, I think commnet#2 is different bug
Status: NEW → UNCONFIRMED
Ever confirmed: false
I'm pretty sure the underlying bug is the same. I did some more testing on the site mentioned in #1. Here's what I've found: The bug doesn't appear with the following CSS on http://catalog.neet.tv/g/: img { opacity: .9;} * {box-shadow: none !important;} * {border: none !important;} This removes all border-styling on the images. I think the combination of opacity<1 and any border-styling of images triggers the bug. Adding a border instead of a box-shadow to my test case also triggered it, while opacity alone didn't. Not sure why it's so hard to trigger the bug in the test case, while it appears one every reload on the mentioned page. Might have to to with the large number of different images on the page.
Summary: Images with box-shadow and opacity not rendering properly sometimes since DLBI → Images with opacity<1 and border styling not rendering properly sometimes since DLBI
I filed Bug 799579 about Comment#2
Summary: Images with opacity<1 and border styling not rendering properly sometimes since DLBI → Images with opacity<1 and border styling sometimes not painted completely since DLBI
Version: 19 Branch → 18 Branch
I haven't been able to reproduce this. Seems like it is similar to bug 799579 though, hopefully it will be fixed.
I was able to reproduce this once, in linux-x64/basic, with attachment 669538 [details]. Subsequent refreshes don't reproduce. Wasn't able to reproduce in win7/d3d10 at all. Does clearing cache or restarting firefox make this easier to repro?
Keywords: qawanted
I just tried both cases with a fresh profile on Linux and had the bug show up easily here. The machine i'm testing this on here is fairly low-end with a single core Atom N270 - I think this could be important, as I'm having a much harder time reproducing on my desktop with it's E8400. Wether the cache is cleared doesn't seem to change anything here initially, but I've noticed that once a page has correctly loaded, subsequent F5 presses reload the page fine. But once I do a no-cache reload with CTRL-F5, incomplete images are back again. Make sure that you CTRL-F5 when testing. Another way your can try: Open both cases in new tabs, switch to another tab for a minute and then return to the tabs. In this case, images don't get painted for me at all until I scroll or F5. I'll try to test this on a 3rd machine later.
Confirming the bug on the third machine, Windows x64 with an i7 920 and latest Nightly using a fresh profile, using the steps from Comment#1. Also, changing to another tab and switching back produces un-painted images like on the other machines.
This has something to do with timing. A way for better reproducability for me is taking the testcase but replace the images with <img src="http://deelay.me/50?http://i.imgur.com/V8QaC.jpg">. Then press ctrl+f5 a few times
Attached file Testcase with delayed images (deleted) —
Attachment #670360 - Attachment mime type: text/plain → text/html
Thanks, it's indeed much easier to reproduce now here and basically happens on every CTRL-F5 for me.
Can anyone still reproduce this? Possibly fixed by bug 795674
I can't. However there is still similar bugs in bug 800206 .
Looks like this got fixed in Nightly 2012-10-12, not sure exactly which bug. I'm resolving this one as I can't reproduce it on any of my machines.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: