Bug 14186 – No back entry created for window.open navigation triggered by non-user-gesture

• Component: History
• Status: RESOLVED FIXED

[Matt Perry]

Executing window.open() from javascript that isn't a user gesture (from an onload handler, for example) doesn't create a back/forward item for the initial navigation in the new window.  I think that any navigation that's not a user gesture also behaves this way, when not all should (for example, adding a 2s timeout in onload to set document.location doesn't add a back/forward item either).

Tested in r23552.  This does not happen in shipping Safari.  

Test case coming.

[Matt Perry]

Created attachment 15074 [details]
window.open test case

Note that you'll need to disable popup blocking to test this.

The window opened from the onload handler doesn't have a back/forward item for the first navigation.

[Matt Perry]

Created attachment 15075 [details]
document.location test case

This test assigns to document.location 2 seconds after loading.  No back/forward item is created for the test page.

There is code in FrameLoader.cpp that sets the frame load type to FrameLoadTypeInternal if the load was not a userGesture.  This load type doesn't add to the BF list.  The load type seems to have originally been meant for subframe loads, and was overloaded for this purpose as well.  Maybe the solution is to create a new load type?  Some non-userGesture loads should add to the BF list, some shouldn't.

[Matt Perry]

The document.location case also fails in shipping Safari.  It passes in Firefox and IE.

[Matt Perry]

This has been fixed since I filed it.