Reftest analyzer doesn't update images properly

RESOLVED FIXED in mozilla15

Status

Testing
Reftest
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: kats, Assigned: kats)

Tracking

Trunk
mozilla15
Other
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

1. Run the reftest analyzer on the android-R1 failure at https://tbpl.mozilla.org/?tree=Try&rev=1392fae7b86c
2. Click on the first failure (test-displayport-bg.html) and view the "Image 2". Observe how there is no image
3. Click on the second failure (test_bug641198.html)
4. Click on the first failure again (test-displayport-bg.html) and view the "Image 2". Observe how there is now an image, and it is the "Image 2" from the second failure.

For some reason the analyzer is unable to properly load the "Image 2" for the first failure, and just shows whatever was last shown when it is requested to show that image.
This probably happens because the base64 image data in the log is interrupted by random lines looking like this:

before 368640, after 368640, break 06ce5000
before 368640, after 368640, break 06ce5000
before 368640, after 368640, break 06ce5000
before 368640, after 368640, break 06ce5000

So the base64 image data parsed out of the log is not a valid image.
Created attachment 628037 [details] [diff] [review]
Patch

Picking Cameron for review since he was the last to make significant changes to that file, I think. Feel free to tag somebody else for review.
Attachment #628037 - Flags: review?(cam)
Assignee: nobody → bugmail.mozilla
Created attachment 628044 [details] [diff] [review]
Patch

Oops, picked up a stray unrelated change in the last patch.
Attachment #628037 - Attachment is obsolete: true
Attachment #628037 - Flags: review?(cam)
Attachment #628044 - Flags: review?(cam)
Comment on attachment 628044 [details] [diff] [review]
Patch

I'm not a fan of the large embedded data URI here.  Can you add this image as a separate file and set the <image>'s xlink:href to reference it on error?  (Or would there be a problem with the getImageData call after drawing that http-referenced image on the canvas, which there wouldn't be with the data: URI one?)
I'm not really a fan of either but I wanted to make sure that the analyzer remained a standalone file. If I move it out into a separate file then anybody using the analyzer as a standalone will have to update to also include the image. Note that if the error image doesn't load it will go into an infinite loop because it will run the error handler again, so that is really an undesirable scenario.
Comment on attachment 628044 [details] [diff] [review]
Patch

OK, fair enough.
Attachment #628044 - Flags: review?(cam) → review+

Comment 8

6 years ago
https://hg.mozilla.org/mozilla-central/rev/17d9f93a9ff7
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.