385649 - [FIX]Using back button to go back to page with Flash content called with object tag causes links in Flash object to be misaligned with display

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[Daniel Naylor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a6pre) Gecko/20070623 Minefield/3.0a6pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a6pre) Gecko/20070623 Minefield/3.0a6pre

If a web page is using object tags to display Flash content on a web page, rather than embed tags, and the flash object is not left-aligned, the page will paint normally when loaded via a link. However, if you navigate away from the page, then use the back button to go back, the flash object will still be in the correct position, but the browser will act as if the flash object is left aligned, and so any clicking hotspots will shift accordingly. Also, any shifted "hotspots" are only clickable if they fall in the original object boundary.

Reloading or resizing the page re-paints the page the flash control works normally again.

This only occurs when a Flash object is called via the object tag. This is not seen when using the embed tag.

This has been tested using a clean profile.

Reproducible: Always

Steps to Reproduce:
1. Load a page with a Flash object that is not aligned to the left that contains clickable areas, for example, the URL above.
2. Navigate away from the page.
3. Click the back button. 
Actual Results:  
The Flash object is painted in the correct place, but the "hotspots" have moved left to the positions that they would be in if the object was left aligned.

Expected Results:  
The Flash object is painted in the correct place, and the "hotspots" are also in the correct positions.

Comment 1

[Martijn Wargers (dead)]

I'm seeing the same with (on windowsXP)
http://stuff.novemberborn.net/sifr/overflow-bug.html
, which comes from bug 271442.
A resize of the window fixes it.

This regressed between 2006-07-17 and 2006-07-18:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-07-17+04&maxdate=2006-07-18+07&cvsroot=%2Fcvsroot
I don't really see anything that might have caused this.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070624 Minefield/3.0a6pre
I can very rarely reproduce this. I tried several URLs, but only about:config caused some change. Regression range is 2006-07-17 15 - 2006-07-17 21.

Comment 3

[Martijn Wargers (dead)]

Thanks, Ria.
I just noticed that bug 343282 was fixed in that timeframe.
That means that bfcache didn't work in older builds, so the regression range we found is not useful :(

Comment 4

[Martijn Wargers (dead)]

Ok, the new regression range I get is:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-12-02+04&maxdate=2005-12-03+09&cvsroot=%2Fcvsroot
In that case I would think the patch for bug 315841 is somehow responsible.

Btw, for me this is always reproducible.
- On the test page, just click on any of the links of the flash object, you get moved to a 404 page.
- Go back. After that, no link in the flash file is clickable anymore.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm...  I can't seem to reproduce on Linux with Flash 7...  Not that surprising, really; the scriptability stuff is all different there.

Martijn, out of curiousity, if you back out just the layout/base/nsPresShell.cpp changes from bug 315841, does the problem go away?

Comment 6

[Matthew Gregan [:kinetik]]

Attachment: testcase

I can reproduce this problem with current trunk on Vista with Flash 9r47.  Reverting the layout/base/nsPresShell.cpp changes from bug 315841 does indeed cause the problem to go away.

It's easy to see the behaviour with the attached minimized testcase and a mouse following Flash applet such as the one from http://www.newtutorials.com/mousef/mouseFollowerTut.swf.  Load any page (to populate the nav history), load the testcase, navigate back the the previous page, then navigate forward to the testcase.  Once you return to the testcase, the ball following the mouse is offset within the Flash content by the same distance as the Flash content is offset from the content area.

Comment 7

[Boris Zbarsky [:bzbarsky]]

OK.  We should trace through the instantiate that comes through on bfcache restore and see what goes wrong, I guess...

Comment 8

[Matthew Gregan [:kinetik]]

This only occurs when the plugin is in windowless mode (caused by wmode="transparent").  It's reproducible using <embed> too, making the obvious modifications to my testcase in comment #6 confirms this.

In nsObjectFrame::PaintPlugin when dealing with a windowless plugin, we send a WM_WINDOWPOSCHANGED message to the plugin if we detect that our window origin has changed (comparing the result of the cached value in mWindowlessRect with the result of calling GetWindowOriginInPixels()).  The first time we paint, mWindowlessRect is still all-zeros, so we go ahead and send the message.

The testcase is failing because we don't send a WM_WINDOWPOSCHANGED message when the document comes back from the bfcache because the current window origin is still the same as what we have cached in mWindowlessRect.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Possible patch

Matthew, thanks for digging into this!  Does this patch help?

Comment 10

[Matthew Gregan [:kinetik]]

That was quick!  Yes, with your patch all of the test cases mentioned in this bug behave correctly.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 289766 [details] [diff] [review]
Possible patch

> That was quick! 

Writing a fix is usually easy once someone hunts down the real problem!  All the real work was in comment 8.

roc, want to review?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fixed.  Would be nice to write a test if we can....