Closed Bug 408898 Opened 14 years ago Closed 13 years ago

Drawing page with drawWindow duplicates flash content

Categories

(Core :: Canvas: 2D, defect, P3)

x86
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla1.9beta4

People

(Reporter: mossop, Assigned: kinetik)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached image screenshot
Don't know if this is us or flash, but when my extension does a drawWindow of a page with a flash movie in it suddenly a second image of the flash movie gets drawn upside-down at the bottom left of the firefox window. See the attachment.

The previous version of flash did not exhibit this, but that was quite old, I am now on 9r115.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2007121804 Firefox/3.0b2pre ID:2007121804
Given the number of extensions around that use drawWindow I think we're going to find people hitting this a lot. We need to figure out if this is flash or us.

My attempts to make a simple testcase are currently being scuppered by bug 406334 unfortunately.
Severity: normal → major
Flags: blocking1.9?
Josh, I bet this is Quartz drawing model stuff.
I suspect this is the same issue and not caused by drawWindow:

Visit http://www.samsung.com/uk/consumer/subtype/subtype.do?group=itbusiness&type=monitors&subtype=lcd
Hover over the menu links across the top of the page.

The flash content jumps around on the page.
Flags: blocking1.9? → blocking1.9+
I see this and I'm pretty sure I don't have any extensions installed.
Dave: is this fixed for you now that bug 395983 has landed?
No this still seems to be a problem
Assignee: vladimir → kinetik
I've actually seen a variant of this bug where the Flash object in a window actually appears upside down at the bottom of another window... looks bad :-). Probably related.
Attached patch patch v1Splinter Review
We need to call SetWindow in more cases.  I haven't worked out exactly which cases yet, so this patch calls SetWindow unconditionally in the CoreGraphics plugin paint path.  We know that we need to call SetWindow if BeginNativeDrawing gives us an off-screen CGContext, but there seem to be other cases we are missing such as those that are causing bug #419187.

I'll follow this patch up with a better one (where we call SetWindow only when necessary) soon, but I think we should get this simple fix in for beta 4.
Attachment #305639 - Flags: superreview?(roc)
Attachment #305639 - Flags: review?(roc)
Blocks: 419187
Forgot to mention that calling SetWindow on each paint doesn't seem to have
negative side effects.  Plugin paint performance (with Flash) isn't obviously
affected (checked with some Flash that displays the current frame rate).
Attachment #305639 - Flags: superreview?(roc)
Attachment #305639 - Flags: superreview+
Attachment #305639 - Flags: review?(roc)
Attachment #305639 - Flags: review+
Woot!
Checked in. I don't suppose there's a way to write a reftest for this?
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
Target Milestone: --- → mozilla1.9beta4
Awesome, thanks!
Status: RESOLVED → VERIFIED
Don't think so, yet -- need bug 372352 fixed first.
Depends on: test-plugin
Flags: in-testsuite?
Well that and drawWindow can't draw plugin content most of the time (bug 313462)
You need to log in before you can comment on or make changes to this bug.