Closed
Bug 1149260
Opened 9 years ago
Closed 9 years ago
PresShell::PaintRangePaintInfo can request a zero-height surface from gfx
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
mozilla40
Tracking | Status | |
---|---|---|
firefox40 | --- | fixed |
People
(Reporter: kats, Assigned: kats)
Details
Attachments
(2 files, 1 obsolete file)
6.74 KB,
text/plain
|
Details | |
2.14 KB,
patch
|
enndeakin
:
review+
|
Details | Diff | Splinter Review |
While attempting to run the browser/base/content/test/newtab/browser_newtab_drag_drop.js mochitest locally on OS X I keep hitting a gfxCriticalError being logged from the gfx code. Stack attached. I do have some local changes but they shouldn't affect this code path. When the PresShell::PaintRangePaintInfo function is called with aArea = nsRect(0, 47640, 64800, 60) and maxSize is computed as nsRect(0, 1320, 86400, 52440) then the pixelArea needs resizing because it's too wide. The scale factor computed is 0.666 and so the pixelArea gets scaled down to have a height of 0. Seems like the PaintRangePaintInfo should detect this and guard against it?
Assignee | ||
Comment 1•9 years ago
|
||
Assignee | ||
Comment 2•9 years ago
|
||
I don't know who owns/knows this code, looks like it's been largely untouched since it was added by Neil 8 years ago except for large refactoring-type changes. Applying the workaround in comment 1 fixes the gfxCriticalError I was seeing, but that test is still causing issues for me and I'm not sure if it's because the workaround is bad or if there are other differences between my local setup and tryserver (or both). If somebody who knows this code can validate/review my workaround it would help.
Flags: needinfo?(enndeakin)
Comment 3•9 years ago
|
||
The code you are citing is used to draw the drag feedback image. Your example suggests that the test is trying to drag something that is 1080 x 1 pixels in size, which can't really be scaled down. The options here would be to crop instead, or just return null to have no feedback. On Mac, this will default to a small rectangle if I remember correctly. So I think your patch here should be ok. You probably also want to adjust the similar code in nsBaseDragService::DrawDragForImage though, which is used specifically when dragging image elements.
Flags: needinfo?(enndeakin)
Assignee | ||
Comment 4•9 years ago
|
||
Thanks for the info!
Assignee: nobody → bugmail.mozilla
Attachment #8585670 -
Attachment is obsolete: true
Attachment #8587340 -
Flags: review?(enndeakin)
Updated•9 years ago
|
Attachment #8587340 -
Flags: review?(enndeakin) → review+
Assignee | ||
Comment 5•9 years ago
|
||
Try https://treeherder.mozilla.org/#/jobs?repo=try&revision=d244b7c68be6 includes this change and looks green. Landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/c236d0f0e428
Comment 6•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/c236d0f0e428
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox40:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in
before you can comment on or make changes to this bug.
Description
•