Closed
Bug 944679
Opened 11 years ago
Closed 11 years ago
Do not return nullptr in DeprecatedTextureHostBasic::GetAsSurface
Categories
(Core :: Graphics: Layers, defect)
Core
Graphics: Layers
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: pehrsons, Assigned: pehrsons)
Details
(Whiteboard: [qa-])
Attachments
(1 file)
943 bytes,
patch
|
nical
:
review+
dvander
:
feedback+
|
Details | Diff | Splinter Review |
To follow up on the comments in bug 907292. It was changed to return nullptr in bug 942318."
Assignee | ||
Comment 1•11 years ago
|
||
Assignee | ||
Comment 2•11 years ago
|
||
Comment on attachment 8340342 [details] [diff] [review] Do not return nullptr in DeprecatedTextureHostBasic::GetAsSurface. This should fix the nullptr in DeprecatedTextureHostBasic. David, adding you here since you wrote the latest patch for GetAsSurface where the nullptr was put in.
Attachment #8340342 -
Flags: review?(nical.bugzilla)
Attachment #8340342 -
Flags: feedback?(dvander)
Comment 3•11 years ago
|
||
Comment on attachment 8340342 [details] [diff] [review] Do not return nullptr in DeprecatedTextureHostBasic::GetAsSurface. Review of attachment 8340342 [details] [diff] [review]: ----------------------------------------------------------------- Sorry for the review lag, I've been a bit busy lately. So, I looked at why the return nullptr was put here in the first place (rather than returning a gfxImageSurface as it was doing before), and apparently this was done in the process of Moz2Difying the TextureHost. Before that, it used to return mThebesSurface, but as mThebesSurface was replaced by its Moz2D counterpart, GetAsSurface simply got it's implem removed. All I wanted to check was that this was not an intentional fix for a bug of the previous implementation, so it's good.
Attachment #8340342 -
Flags: review?(nical.bugzilla) → review+
Assignee | ||
Comment 4•11 years ago
|
||
Cool, so what's the standard procedure for getting the patch in? It is the responsibility of the assignee to get everything through I gather? And in my case that would be by setting the checkin-needed flag? What's the policy on running tests before check-in? Do you routinely push things to try? Would a bad patch get caught on inbound in the worst case?
Updated•11 years ago
|
Attachment #8340342 -
Flags: feedback?(dvander) → feedback+
Updated•11 years ago
|
Keywords: checkin-needed
Updated•11 years ago
|
Assignee: nobody → pehrsons
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 5•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/a7c22bdbf800
Keywords: checkin-needed
Comment 6•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a7c22bdbf800
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Updated•10 years ago
|
Whiteboard: [qa-]
You need to log in
before you can comment on or make changes to this bug.
Description
•