Closed
Bug 995745
Opened 11 years ago
Closed 11 years ago
[OMTC] New Google maps turn black after loading
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
VERIFIED
FIXED
mozilla32
Tracking | Status | |
---|---|---|
e10s | + | --- |
firefox30 | --- | unaffected |
firefox31 | - | affected |
firefox32 | --- | verified |
People
(Reporter: jmjjeffery, Assigned: roc)
References
(Depends on 1 open bug)
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
patch
|
mattwoodrow
:
review+
|
Details | Diff | Splinter Review |
Was pointed out to me this morning that the 'New Google Maps' is fading to 'black' after initial page load.
STR:
Enable OMTC
Load Google Maps and opt into the 'new maps' if your not already
Once the page loads, it turns black
Turning 'off' OMTC fixes the blackness
This is a regression as this was 'fixed' once by bug 975824
Reporter | ||
Comment 1•11 years ago
|
||
Tested on Win7 x64 with latest hourly tinderbox build cset:
https://hg.mozilla.org/mozilla-central/rev/ebdf2740dc3e
Reporter | ||
Comment 2•11 years ago
|
||
This may be a slight variation of bug 975824, as there was a re-vamped test added in that bug to catch the issue with compression.
Either the test is not working, or this is a different case.
Comment 3•11 years ago
|
||
Regression window(m-i):
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5f286e259379
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 ID:20140401004332
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d1f8ac35bdd4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 ID:20140401005432
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5f286e259379&tochange=d1f8ac35bdd4
Regressed by: Bug 990338
status-firefox30:
--- → unaffected
status-firefox31:
--- → affected
tracking-firefox31:
--- → ?
Keywords: regressionwindow-wanted
Comment 4•11 years ago
|
||
Matt, do you think it could be a regression from the Moz2D work in bug 990338? If so, what's the timeline you could take a look at this? It appears to be the same as bug 994969, and e10s is identifying it as their biggest pain in the ... dog-fooding.
Flags: needinfo?(matt.woodrow)
Comment 5•11 years ago
|
||
This is because the Moz2D code path in CopyableCanvasLayer that I switched us over to does crazy things. It's taking a snapshot of the destination, and abusing copy-on-write behaviour to write directly into the destination. This works on some Moz2D backends, so we got away with it for a while.
roc is going to fix this as part of his current work on clarifying the mutability of SourceSurfaces.
Flags: needinfo?(matt.woodrow)
Updated•11 years ago
|
tracking-e10s:
--- → +
Comment 10•11 years ago
|
||
Bug 997758 seems to be stuck for the moment so I've extracted the bit that's needed to fix this bug.
Patch is by roc, r=me
Attachment #8414953 -
Flags: review+
Comment 11•11 years ago
|
||
Updated•11 years ago
|
Assignee: nobody → roc
Comment 12•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Comment 14•11 years ago
|
||
Reprouced Nightly 2014-04-28, Win 7 x64.
Verified fixed 32.0a1 (2014-05-06).
Status: RESOLVED → VERIFIED
status-firefox32:
--- → verified
Comment 15•10 years ago
|
||
Robert, the bug is marked as affecting 31 but we didn't receive any uplift request. So, is the bug exist in 31 or the uplift request is missing? Thanks
Flags: needinfo?(roc)
Assignee | ||
Comment 16•10 years ago
|
||
This only affects OMTC so we don't need an uplift to 31 since OMTC isn't on by default there.
Flags: needinfo?(roc)
You need to log in
before you can comment on or make changes to this bug.
Description
•