Closed Bug 995745 Opened 11 years ago Closed 11 years ago

[OMTC] New Google maps turn black after loading

Categories

(Core :: Graphics: CanvasWebGL, defect)

Product:
Core
Component:
Graphics: CanvasWebGL
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla32
Tracking Flags:
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)

Fix CopyableCanvasLayer
6.31 KB, 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
Tested on Win7 x64 with latest hourly tinderbox build cset: https://hg.mozilla.org/mozilla-central/rev/ebdf2740dc3e
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.
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
Blocks: 990338
No longer blocks: 975824
status-firefox30: --- → unaffected
status-firefox31: --- → affected
tracking-firefox31: --- → ?
Keywords: regressionwindow-wanted
Blocks: 899785
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)
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)
Depends on: 997758
Going to track this
tracking-firefox31: ? → +
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+
Assignee: nobody → roc
https://hg.mozilla.org/mozilla-central/rev/2468eeb92c8d
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Depends on: 1006198
Reprouced Nightly 2014-04-28, Win 7 x64. Verified fixed 32.0a1 (2014-05-06).
Status: RESOLVED → VERIFIED
status-firefox32: --- → verified
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)
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.

Attachment

General

Creator:
Created:
Updated:
Size: