Closed Bug 863635 Opened 7 years ago Closed 7 years ago

Windows taskbar previews don't show the address bar

Categories

(Core :: Canvas: 2D, defect)

All
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla24
Tracking Status
firefox20 --- affected
firefox21 --- affected
firefox22 --- affected
firefox23 --- affected
firefox24 + verified

People

(Reporter: MattN, Assigned: nrc)

References

()

Details

(Keywords: regression)

Attachments

(2 files)

STR:
1) Set browser.taskbar.previews.enable = true (may need a restart?)
2) Open only a few tabs since we stop showing previews at some point
3) Mouse over the Firefox taskbar button
4) Mouse over the tab previews

Expected result:
The browser window should look like it does normally.  The awesome bar should be shown.

Actual result:
The image of the browser window doesn't include the address bar.

Last Good: 2012-09-20
First Bad: 2012-10-09 (intermediate nightlies have crashes upon hovering the taskbar preview)

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-09-20&enddate=2012-10-09

It seems like this is implemented using drawWindow on a 2D Canvas[1] so I suspect the following landing in that range is related:
http://hg.mozilla.org/mozilla-central/rev/a5cb3eecff37	Robert O'Callahan
Bug 772726. Make nsCanvasRenderingContext2DAzure::DrawWindow use Azure content drawing if that's enabled. r=bas

[1] http://hg.mozilla.org/mozilla-central/annotate/d1847d734c77/browser/modules/WindowsPreviewPerTab.jsm#l307
Requesting tracking-firefox24 since I suspect fixing this will fix bug 857649 which is targeted to ship in Firefox 24 and makes this problem more noticeable (see attachment 732903 [details]).
Roc: can you or someone else look into this? It seems to be an existing bug, but apparently will become more visible with Australis.
Flags: needinfo?(roc)
Nick Cameron can work on this.
Assignee: nobody → ncameron
Flags: needinfo?(roc)
Background: the first cause of the bug was that the clip set on the gfxContext in nsSVGClipPathFrame::ClipPaint was causing incorrect clipping. By painting the clip path rather than clipping with it I could see the path and transform were correct. I verified that there was no existing path or clip on the context. It turns out clipping was just broken. (This is called from nsSVGIntegrationUtils::PaintFramesWithEffects, btw. The awesome bar is wrapped in SVG effects, which causes an inactive layer (which means we paint with basic layers)).

Clipping is broken because the gfxContext was wrapping a DrawTargetCairo, that is it was doing Azure content drawing using Cairo, which is not yet supported. I filed bug 877558 for some dodgy clipping in the Azure backend, I'm not sure whether that will fix this bug or not, I encountered it when trying to experiment with the clipping).

One solution would be to always use a Thebes gfxContext in drawWindow, but that s undesirable because we will forget about it once Azure/Cairo content is done. Checking for Cairo surfaces in particular is a bad idea because Skia. So this patch is a little more complex than necessary, but I think it is future proof and adds functionality we might want elsewhere too.
Attachment #756400 - Flags: review?(bas) → review+
Depends on: 878522
Try run: https://tbpl.mozilla.org/?tree=Try&rev=dfa40b556ca0

Linux is busted due to bug 878522.
https://hg.mozilla.org/mozilla-central/rev/486ec13ac5d7
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Thanks! The addressbar now appears in taskbar previews on Windows 7.
Blocks: 857649
Status: RESOLVED → VERIFIED
Verified fixed on Fx 24 beta 9, buildID 20130905180733.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
QA Contact: petruta.rasa
You need to log in before you can comment on or make changes to this bug.