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.

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.

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.

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 :(

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.

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?

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.

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

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.

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

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

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?

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