Closed
Bug 391028
Opened 17 years ago
Closed 17 years ago
drawImage with broken PNG draws random memory
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: philip, Assigned: vlad)
References
Details
(4 keywords, Whiteboard: [sg:low])
Attachments
(4 files)
465 bytes,
text/html
|
Details | |
912 bytes,
patch
|
pavlov
:
review+
dveditz
:
approval1.8.1.10+
pavlov
:
approval1.9+
|
Details | Diff | Splinter Review |
1.15 KB,
patch
|
pavlov
:
review+
dveditz
:
approval1.8.1.11+
dveditz
:
approval1.8.1.12+
|
Details | Diff | Splinter Review |
1.14 KB,
patch
|
caillon
:
approval1.8.0.next+
|
Details | Diff | Splinter Review |
User-Agent: Opera/9.22 (X11; Linux i686; U; en) Build Identifier: With a broken PNG file (which causes "The image [...] cannot be displayed, because it contains errors." when opened in the browser normally), calling drawImage results in random stuff being drawn onto the canvas each time the page is reloaded. Reproduced with: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007080504 Minefield/3.0a8pre Couldn't reproduce in Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a8pre) Gecko/2007080505 Minefield/3.0a8pre (it only ever gave a black rectangle). HTML 5 says at http://www.whatwg.org/specs/web-apps/current-work/#complete that img.complete should be false if the image wasn't valid, and http://www.whatwg.org/specs/web-apps/current-work/#drawimage says that should cause INVALID_STATE_ERR in drawImage. Reproducible: Always
Reporter | ||
Comment 1•17 years ago
|
||
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•17 years ago
|
Flags: blocking1.9?
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → vladimir
Flags: blocking1.9? → blocking1.9+
Assignee | ||
Comment 2•17 years ago
|
||
This should fix it; something similar can go in on the branch.
Attachment #282781 -
Flags: review?(pavlov)
Updated•17 years ago
|
Attachment #282781 -
Flags: review?(pavlov)
Attachment #282781 -
Flags: review+
Attachment #282781 -
Flags: approval1.9+
Assignee | ||
Updated•17 years ago
|
Attachment #282781 -
Flags: approval1.8.1.9?
Assignee | ||
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: in-testsuite?
Assignee | ||
Comment 3•17 years ago
|
||
Wrong line in the previous patch, sigh.
Updated•17 years ago
|
Flags: blocking1.8.1.10+
Whiteboard: [sg:low]
Comment 4•17 years ago
|
||
Comment on attachment 282781 [details] [diff] [review] add a check for completed load status approved for 1.8.1.10, a=dveditz for release-drivers
Attachment #282781 -
Flags: approval1.8.1.10? → approval1.8.1.10+
Comment 6•17 years ago
|
||
verified fixed 1.8.1.10 using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.10) Gecko/2007111504 Firefox/2.0.0.10 and the testcase - adding verified keyword
Keywords: fixed1.8.1.10 → verified1.8.1.10
Updated•17 years ago
|
Group: security
Has this caused bug 405584?
Comment 8•17 years ago
|
||
(In reply to comment #7) > Has this caused bug 405584? > yes, the followup attachment 284556 [details] [diff] [review] wasn't checked in.
Updated•17 years ago
|
Attachment #284556 -
Flags: review?(pavlov)
Updated•17 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 9•17 years ago
|
||
This is still FIXED on the trunk. Bug 405584 tracks the branch regression.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Depends on: 405584
Resolution: --- → FIXED
Updated•17 years ago
|
Attachment #284556 -
Flags: review?(pavlov) → review+
Updated•17 years ago
|
Attachment #284556 -
Flags: approval1.8.1.11?
Comment 10•17 years ago
|
||
Comment on attachment 284556 [details] [diff] [review] er. followup. appears to have landed, though without approval. (Granted, I do feel its a safe and needed landing, but I wonder why it skipped approval)
Comment 11•17 years ago
|
||
(In reply to comment #10) > (From update of attachment 284556 [details] [diff] [review]) > appears to have landed, though without approval. (Granted, I do feel its a safe > and needed landing, but I wonder why it skipped approval) The patch had a=release-drivers to land. The flag just wasn't marked as such on the patch. I'm sure dveditz or somebody will set the flag when they get to it, but it definitely had approval to land. :)
Updated•17 years ago
|
Attachment #284556 -
Flags: approval1.8.1.12?
Attachment #284556 -
Flags: approval1.8.1.12+
Attachment #284556 -
Flags: approval1.8.1.11+
Updated•17 years ago
|
Keywords: fixed1.8.1.11,
fixed1.8.1.12
Comment 12•17 years ago
|
||
Sorry for the missing approvals, this one-bugfix release was mostly handled real-time on IRC. Nick had approvals to land on the _RELBRANCH and the mozilla 1.8 branch
Comment 13•17 years ago
|
||
Verified for 1.8.1.12 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12pre) Gecko/2008012208 BonEcho/2.0.0.12pre.
Keywords: fixed1.8.1.12 → verified1.8.1.12
Comment 14•16 years ago
|
||
Attachment #307242 -
Flags: approval1.8.0.15?
Updated•16 years ago
|
Flags: blocking1.8.0.15+
Comment 15•16 years ago
|
||
Comment on attachment 307242 [details] [diff] [review] combined for 1.8.0 a=caillon for 1.8.0.15
Attachment #307242 -
Flags: approval1.8.0.15? → approval1.8.0.15+
Comment 16•16 years ago
|
||
Attachment 307242 [details] [diff] committed to 1.8.0 branch
Keywords: fixed1.8.0.15
You need to log in
before you can comment on or make changes to this bug.
Description
•