Bug 12005 – REGRESSION(r17256-17272): Multiple history entries created

• Component: History
• Status: RESOLVED FIXED

[David Carson]

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.

[Mark Rowe (bdash)]

<rdar://problem/4928650>

[Brady Eidson]

Theres been alot of loader and history work done lately...  any chance you can regress this using the nightlys?

[Matt Lilek]

This is still happening with r18892

[Brady Eidson]

Regress using the nightlys, meaning going back through the nightlys and seeing where the problem first appears

[Mark Rowe (bdash)]

The additional history entries come from the titles advertisements that are displayed in iframes.

[Mark Rowe (bdash)]

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.

[Mark Rowe (bdash)]

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.

[Maciej Stachowiak]

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

[Maciej Stachowiak]

From duplicate: <rdar://problem/4921797>

[Darin Adler]

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

[Brady Eidson]

Using the reduction, I regressed this further with the nightlies to the 17256-17272 range

[Brady Eidson]

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.

[Brady Eidson]

The reduction Mark posted way key - it was well understood and a fix was committed in r20813!  Yay!