Bug 12005 - REGRESSION(r17256-17272): Multiple history entries created
Summary: REGRESSION(r17256-17272): Multiple history entries created
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: History (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Nobody
URL: http://cbs4boston.com/
Keywords: HasReduction, InRadar, Regression
: 12650 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-12-27 14:20 PST by David Carson
Modified: 2007-04-09 17:22 PDT (History)
3 users (show)

See Also:


Attachments
Reduction (298 bytes, text/html)
2007-01-24 21:20 PST, Mark Rowe (bdash)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Carson 2006-12-27 14:20:42 PST
When I load CBS4Boston web site, three history entries are created. The history items are the original page, and two entitled 'Click here to find out more!'
Loading the same site in shipping Safari and FF, only one history entry is created.

Marked it as regression as this is not a problem in shipping safari.
Comment 1 Mark Rowe (bdash) 2007-01-16 19:19:22 PST
<rdar://problem/4928650>
Comment 2 Brady Eidson 2007-01-16 19:30:39 PST
Theres been alot of loader and history work done lately...  any chance you can regress this using the nightlys?
Comment 3 Matt Lilek 2007-01-16 19:35:39 PST
This is still happening with r18892
Comment 4 Brady Eidson 2007-01-16 20:30:12 PST
Regress using the nightlys, meaning going back through the nightlys and seeing where the problem first appears
Comment 5 Mark Rowe (bdash) 2007-01-24 20:22:21 PST
The additional history entries come from the titles advertisements that are displayed in iframes.
Comment 6 Mark Rowe (bdash) 2007-01-24 20:33:26 PST
This regression would appear to be introduced between r17256 and r17282, but it's hard to narrow it down further as the URL in question crashes the nightly builds in that range.
Comment 7 Mark Rowe (bdash) 2007-01-24 21:20:38 PST
Created attachment 12659 [details]
Reduction

The ad-related JS on the page creates an iframe via document.write, then straight away sets its src property.  It appears that setting the src property to the same value is triggering a fresh load which creates a history entry.
Comment 8 Maciej Stachowiak 2007-02-07 05:40:53 PST
*** Bug 12650 has been marked as a duplicate of this bug. ***
Comment 9 Maciej Stachowiak 2007-02-07 05:42:27 PST
From duplicate: <rdar://problem/4921797>
Comment 10 Darin Adler 2007-03-11 10:35:51 PDT
(In reply to comment #7)
> The ad-related JS on the page creates an iframe via document.write, then
> straight away sets its src property.  It appears that setting the src property
> to the same value is triggering a fresh load which creates a history entry.

Setting the src property is always supposed to cause a reload. But that was buggy in older version of WebKit. It didn't trigger a load if the URL was the same. It's possible that we need to trigger a load yet somehow know not to put things in the back/forward list in this case.
Comment 11 Brady Eidson 2007-04-03 17:56:37 PDT
Using the reduction, I regressed this further with the nightlies to the 17256-17272 range
Comment 12 Brady Eidson 2007-04-03 18:49:52 PDT
This broke in http://trac.webkit.org/projects/webkit/changeset/17267
Geoff's seemingly simplistic change that was attempting to clean up loading code, but there's something subtle it tweaked re: user gesture versus non-user gesture here that I need to figure out.
Comment 13 Brady Eidson 2007-04-09 17:22:50 PDT
The reduction Mark posted way key - it was well understood and a fix was committed in r20813!  Yay!