Bug 9166 – Setting iframe.src is not registered in history

• Component: History
• Status: RESOLVED FIXED

[David Kilzer (:ddkilzer)]

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.

[David Kilzer (:ddkilzer)]

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.

[David Kilzer (:ddkilzer)]

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.

[David Kilzer (:ddkilzer)]

May be fixed by:  http://trac.webkit.org/projects/webkit/changeset/24353

[David Kilzer (:ddkilzer)]

(In reply to comment #3)
> May be fixed by:  http://trac.webkit.org/projects/webkit/changeset/24353

It was not fixed by this change.

[Eric Seidel (no email)]

*** Bug 9145 has been marked as a duplicate of this bug. ***

[David Kilzer (:ddkilzer)]

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

[David Kilzer (:ddkilzer)]

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).

[Zach Leatherman]

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)

[Darin Fisher (:fishd, Google)]

I have a patch for this.

[Darin Fisher (:fishd, Google)]

Created attachment 51122 [details]
v1 patch

[Darin Fisher (:fishd, Google)]

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

[Adam Barth]

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.  :)

[Darin Fisher (:fishd, Google)]

(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

[Darin Fisher (:fishd, Google)]

Landed as http://trac.webkit.org/changeset/56223

[Adam Barth]

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-->-->'
 --------

[Artur]

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

[Darin Fisher (:fishd, Google)]

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

[Darth]

Isn't this similar to this bug
http://code.google.com/p/chromium/issues/detail?id=16810