Bug 9166 - Setting iframe.src is not registered in history
Summary: Setting iframe.src is not registered in history
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: History (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Darin Fisher (:fishd, Google)
URL:
Keywords: HasReduction
: 9145 (view as bug list)
Depends on: 36382 9150
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-29 18:10 PDT by David Kilzer (:ddkilzer)
Modified: 2013-04-20 06:09 PDT (History)
7 users (show)

See Also:


Attachments
Test v1 (2.72 KB, patch)
2006-05-29 18:18 PDT, David Kilzer (:ddkilzer)
no flags Details | Formatted Diff | Diff
Test case for frames (636 bytes, application/x-gzip)
2007-11-17 20:46 PST, David Kilzer (:ddkilzer)
no flags Details
v1 patch (7.90 KB, patch)
2010-03-18 22:48 PDT, Darin Fisher (:fishd, Google)
abarth: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Kilzer (:ddkilzer) 2006-05-29 18:10:45 PDT
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.
Comment 1 David Kilzer (:ddkilzer) 2006-05-29 18:18:54 PDT
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.
Comment 2 David Kilzer (:ddkilzer) 2007-05-23 20:44:03 PDT
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.
Comment 3 David Kilzer (:ddkilzer) 2007-07-17 07:48:44 PDT
May be fixed by:  http://trac.webkit.org/projects/webkit/changeset/24353

Comment 4 David Kilzer (:ddkilzer) 2007-07-22 20:36:19 PDT
(In reply to comment #3)
> May be fixed by:  http://trac.webkit.org/projects/webkit/changeset/24353

It was not fixed by this change.
Comment 5 Eric Seidel (no email) 2007-09-30 11:19:40 PDT
*** Bug 9145 has been marked as a duplicate of this bug. ***
Comment 6 David Kilzer (:ddkilzer) 2007-11-17 20:37:14 PST
(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.

Comment 7 David Kilzer (:ddkilzer) 2007-11-17 20:46:23 PST
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).
Comment 8 Zach Leatherman 2008-08-23 10:47:01 PDT
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)
Comment 9 Darin Fisher (:fishd, Google) 2010-03-18 21:36:05 PDT
I have a patch for this.
Comment 10 Darin Fisher (:fishd, Google) 2010-03-18 22:48:46 PDT
Created attachment 51122 [details]
v1 patch
Comment 11 Darin Fisher (:fishd, Google) 2010-03-18 22:50:40 PDT
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 12 Adam Barth 2010-03-19 00:14:17 PDT
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.  :)
Comment 13 Darin Fisher (:fishd, Google) 2010-03-19 00:26:57 PDT
(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
Comment 14 Darin Fisher (:fishd, Google) 2010-03-19 00:32:15 PDT
Landed as http://trac.webkit.org/changeset/56223
Comment 15 Adam Barth 2010-03-19 01:27:27 PDT
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-->-->'
 --------
Comment 16 Artur 2010-06-03 07:08:30 PDT
(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!
Comment 17 Darin Fisher (:fishd, Google) 2010-06-08 12:56:57 PDT
(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?
Comment 18 Darth 2010-08-17 13:56:54 PDT
Isn't this similar to this bug
http://code.google.com/p/chromium/issues/detail?id=16810