WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
14186
No back entry created for window.open navigation triggered by non-user-gesture
https://bugs.webkit.org/show_bug.cgi?id=14186
Summary
No back entry created for window.open navigation triggered by non-user-gesture
Matt Perry
Reported
2007-06-15 16:56:12 PDT
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.
Attachments
window.open test case
(210 bytes, text/html)
2007-06-15 16:57 PDT
,
Matt Perry
no flags
Details
document.location test case
(178 bytes, text/html)
2007-06-15 17:02 PDT
,
Matt Perry
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Matt Perry
Comment 1
2007-06-15 16:57:44 PDT
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
Comment 2
2007-06-15 17:02:40 PDT
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
Comment 3
2007-06-15 17:23:38 PDT
The document.location case also fails in shipping Safari. It passes in Firefox and IE.
Matt Perry
Comment 4
2007-08-16 11:25:03 PDT
This has been fixed since I filed it.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug