Closed Bug 580873 Opened 14 years ago Closed 13 years ago

Intermittent failure in layout/reftests/image/background-image-zoom-1.html

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla2.0b12

People

(Reporter: ehsan.akhgari, Assigned: bzbarsky)

References

Details

(Keywords: intermittent-failure, regression)

Attachments

(3 files)

Reftest failure log
14.01 KB, text/plain
Details
failure log with NSPR_LOG_MODULES=imgRequest:5
16.21 KB, text/plain
Details
orange fix
1.37 KB, patch
longsonr
: review-
Details | Diff | Splinter Review
Attached file Reftest failure log — 
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1279764363.1279766481.2476.gz&fulltext=1#err0
Rev3 Fedora 12 mozilla-central debug test reftest on 2010/07/21 19:06:03
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1281183808.1281184505.29317.gz
Rev3 MacOSX Snow Leopard 10.6.2 mozilla-central opt test reftest

s: talos-r3-snow-014
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_snowleopard_test-reftest/build/reftest/tests/layout/reftests/image/background-image-zoom-1.html |
Attachment #459289 - Attachment mime type: application/octet-stream → text/plain
In the log in comment 12, the test is blank and the reftest shows nothing.  Same for the log in comment 11.

Could the handling of invalidation be broken for zoom reftests, or something like that?  Or is the image load not delaying onload as it should?
philringnalda%gmail.com
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1282271610.1282272397.23280.gz
Rev3 MacOSX Snow Leopard 10.6.2 mozilla-central opt test reftest on 2010/08/19 19:33:30

s: talos-r3-snow-026
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_snowleopard_test-reftest/build/reftest/tests/layout/reftests/image/background-image-zoom-1.html |
OS: Linux → All
Two things, one seeming sort of sensible, and one not at all.

Sometime in late December, hard to tell exactly when because there weren't enough pushes happening, this went from being fairly rare to being a top-10 failure (it's number 4 for the current week). http://brasstacks.mozilla.com/couchdb/orange_factor/_design/woo/orange.html?display=Bug&bugid=580873&startday=2010-11-09&endday=2011-01-09 makes 2010-12-19, when bug 617152 landed, look reasonable for that.

Then, between comment 76 and comment 77, we went from getting a blank test image and a good ref image to getting a good test image and a blank ref image (in the ones I spot-checked, I didn't actually check every single one before or after). Nothing in http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=52b229f6a051&tochange=95782553234c looks vaguely reasonable for that.
(In reply to comment #125)
> Then, between comment 76 and comment 77, we went from getting a blank test
> image and a good ref image to getting a good test image and a blank ref image
> (in the ones I spot-checked, I didn't actually check every single one before or
> after). Nothing in
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=52b229f6a051&tochange=95782553234c
> looks vaguely reasonable for that.

Unfortunately there are a blank test image and a good ref image in comment 127.
So the failure must be random.
I could get the failure log with NSPR_LOG_MODULES=imgRequest:5.

According to this log, imgStatusTracker::SyncNotify was processed before loading the image (big.png at this time) so the snapshot image was a blank.
Attachment #508628 - Attachment mime type: text/x-log → text/plain
(In reply to comment #243)
> Created attachment 508628 [details]
> failure log with NSPR_LOG_MODULES=imgRequest:5
> 
> I could get the failure log with NSPR_LOG_MODULES=imgRequest:5.
> 
> According to this log, imgStatusTracker::SyncNotify was processed before
> loading the image (big.png at this time) so the snapshot image was a blank.

The SyncNotify is caused by drawWindow in reftest.js, so I think it's too early to get a snapshot for reftest.

Is window.onload event always fired after background images in CSS are loaded? At least on this test, it seems not.
Attached patch orange fix — — Splinter Review 
When setting background-image for html element, this test case sometimes doesn't work.  It doesn't seem to wait completion of background-image for html element.  As long as I test, it works it for body element instead of.

So, this test hits another bug.  If this change is OK, I will file a new bug.
Attachment #509690 - Flags: review?(longsonr)
Comment on attachment 509690 [details] [diff] [review]
orange fix

The test is a test for bug 486933 to ensure background-image works on html elements. If you test something else you're not really testing the code change in that bug any more.
Attachment #509690 - Flags: review?(longsonr) → review-
(In reply to comment #266)
> Comment on attachment 509690 [details] [diff] [review]
> orange fix
> 
> The test is a test for bug 486933 to ensure background-image works on html
> elements. If you test something else you're not really testing the code change
> in that bug any more.

This test doesn't work now.  Although I don't know regression range for this failure, does this test works when bug 486933 is fixed?
Keywords: regression
I forget adding longsonr...  see comment #267.
Blocks: 486933
The first orange in comment 0 seemed to show up over a year after the patch landed so I imagine it worked pretty much OK till then.
(In reply to comment #265)
> So, this test hits another bug.  If this change is OK, I will file a new bug.

I filed bug 631682.
Depends on: 631682
(In reply to comment #269)
> The first orange in comment 0 seemed to show up over a year after the patch
> landed so I imagine it worked pretty much OK till then.

longsonr, but this test case doesn't work now.  So could we turn off this test until bug 631682 is fixed?

It is too hard that we look for regression range since first failure is 9 month ago, and this is not good test case because *-ref.html is often failure (*-ref.html returns blank).  As test case, bug 631682 is better.
I think this issue has been solved by Boris's wonderful fix for bug 631682.
Assignee: nobody → bzbarsky
Status: NEW → RESOLVED
Closed: 13 years ago
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b12
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: