Setting iframe.src to load a page in an iframe does not cause that URL to be recorded in the history. When a link to the previously loaded page appears later, that link is rendered as unvisited rather than visited. In Firefox 1.5.0.3 on Mac OS X, a page loaded via iframe.src is recorded in history. In MSIE 6 on WinXP SP2, a page loaded via iframe.src is NOT recorded in history. This behavior occurs in Safari 2.0.3 (417.9.3) on Mac OS X 10.4.6 (8I127) as well as locally-built WebKit r14619.
Created attachment 8599 [details] Test v1 Test demonstrating the problem with setting iframe.src. It may be possible to simplify this test. Note that there is commented-out code in the iframe.src-history.js file that will make the test run faster. It should be used in place of the slower code if this test is checked in.
NOTE: I filed this bug because I noticed a difference in behavior between Safari/WebKit, Firefox and MSIE 6. I do not know what the correct behavior is.
May be fixed by: http://trac.webkit.org/projects/webkit/changeset/24353
(In reply to comment #3) > May be fixed by: http://trac.webkit.org/projects/webkit/changeset/24353 It was not fixed by this change.
*** Bug 9145 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > *** Bug 9145 has been marked as a duplicate of this bug. *** Bug 9145 is the same issue of setting the src attribute on <frame> elements.
Created attachment 17334 [details] Test case for frames This test case demonstrates behavior when frame.src (originally Bug 9145) is set either via user action (clicking a button) or through an automated JavaScript call (setTimeout()). Safari 3.0.4 (523.12) with its original WebKit (and Safari 2.0.4 w/original WebKit) - Both user-driven and JavaScript-driven tests "fail" because clicking the browser Back button takes the user back two load events (to the previous page) instead of just one (to the previous frame state). Firefox 2.0.0.9 and Opera 9.22 on Mac OS X 10.4.11; MSIE 7 on Win XP - Both user-driven and JavaScript-driven tests "pass" because clicking the browser Back button takes the user back one load event (to the previous frame state) instead of two (to the previous page).
Not just the "src" attribute, I've seen changing location.hash of an iframe not registering in the history as well. Version 3.1.2 (525.21)
I have a patch for this.
Created attachment 51122 [details] v1 patch
This patch just mimics what we do for assignment to location.href in the case where the frame is already in the document. Otherwise, assignment to "src" behaves as it did before. This behavior is spec'd here: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element
Comment on attachment 51122 [details] v1 patch Ugg. I dislike these infinite parameter lists, but I'll take care of that when I get back to working on FrameLoader. LGTM + svn:eol-style ^^ We don't usually set eol-style on tests. We're going to have a war of fixing four-digit bugs once I get around to fixing the Document.load bug. :)
(In reply to comment #12) > (From update of attachment 51122 [details]) > Ugg. I dislike these infinite parameter lists, but I'll take care of that when > I get back to working on FrameLoader. Yeah, it bugs me too. But, I decided to error in favor of consistency for now. > + svn:eol-style > ^^ We don't usually set eol-style on tests. That's probably my auto-props kicking in :-/ > We're going to have a war of fixing four-digit bugs once I get around to fixing > the Document.load bug. :) lol
Landed as http://trac.webkit.org/changeset/56223
Looks like your new test is flaky: fast/loader/frame-src-change-added-to-history.html -> failed --- /Volumes/Big/WebKit-BuildSlave/leopard-intel-debug-tests/build/layout-test-results/fast/loader/frame-src-change-added-to-history-expected.txt 2010-03-19 01:16:25.000000000 -0700 +++ /Volumes/Big/WebKit-BuildSlave/leopard-intel-debug-tests/build/layout-test-results/fast/loader/frame-src-change-added-to-history-actual.txt 2010-03-19 01:16:25.000000000 -0700 @@ -1,3 +1,5 @@ + + -------- Frame: '<!--framePath //<!--frame0-->-->' --------
(In reply to comment #15) > Looks like your new test is flaky: > > fast/loader/frame-src-change-added-to-history.html -> failed > Hi, I was wondering what's the status of this fix? (Sorry, I'm not quite familiar with Changesets, and how and when they make their way to a nightly build). I have the most recent WebKit nightly build, and iframe.src doesn't seem to get added to the browser history. Thanks!
(In reply to comment #16) > (In reply to comment #15) > > Looks like your new test is flaky: > > > > fast/loader/frame-src-change-added-to-history.html -> failed > > > > Hi, I was wondering what's the status of this fix? (Sorry, I'm not quite familiar with Changesets, and how and when they make their way to a nightly build). The test result was corrected in http://trac.webkit.org/changeset/56240 > I have the most recent WebKit nightly build, and iframe.src doesn't seem to get added to the browser history. Hmm... I tested a tip-of-tree Chromium build, and I see that the visited state of the URLs is recorded, so that links to the page navigated to via frame.src assignment do show up as visited. Chromium purposely excludes subframe navigations from its global history system though. Perhaps Safari does something similar?
Isn't this similar to this bug http://code.google.com/p/chromium/issues/detail?id=16810