Bug 9166 - Setting iframe.src is not registered in history
: Setting iframe.src is not registered in history
Status: RESOLVED FIXED
: WebKit
History
: 420+
: Macintosh Mac OS X 10.4
: P2 Normal
Assigned To:
:
: HasReduction
: 9150 36382
:
  Show dependency treegraph
 
Reported: 2006-05-29 18:10 PST by
Modified: 2013-04-20 06:09 PST (History)


Attachments
Test v1 (2.72 KB, patch)
2006-05-29 18:18 PST, David Kilzer (:ddkilzer)
no flags Review Patch | 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 PST, Darin Fisher (:fishd, Google)
abarth: review+
Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-05-29 18:10:45 PST
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 From 2006-05-29 18:18:54 PST -------
Created an attachment (id=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 From 2007-05-23 20:44:03 PST -------
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 From 2007-07-17 07:48:44 PST -------
May be fixed by:  http://trac.webkit.org/projects/webkit/changeset/24353
------- Comment #4 From 2007-07-22 20:36:19 PST -------
(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 From 2007-09-30 11:19:40 PST -------
*** Bug 9145 has been marked as a duplicate of this bug. ***
------- Comment #6 From 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 From 2007-11-17 20:46:23 PST -------
Created an attachment (id=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 From 2008-08-23 10:47:01 PST -------
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 From 2010-03-18 21:36:05 PST -------
I have a patch for this.
------- Comment #10 From 2010-03-18 22:48:46 PST -------
Created an attachment (id=51122) [details]
v1 patch
------- Comment #11 From 2010-03-18 22:50:40 PST -------
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 From 2010-03-19 00:14:17 PST -------
(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.

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 From 2010-03-19 00:26:57 PST -------
(In reply to comment #12)
> (From update of attachment 51122 [details] [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 From 2010-03-19 00:32:15 PST -------
Landed as http://trac.webkit.org/changeset/56223
------- Comment #15 From 2010-03-19 01:27:27 PST -------
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 From 2010-06-03 07:08:30 PST -------
(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 From 2010-06-08 12:56:57 PST -------
(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 From 2010-08-17 13:56:54 PST -------
Isn't this similar to this bug
http://code.google.com/p/chromium/issues/detail?id=16810