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.
<rdar://problem/4928650>
Theres been alot of loader and history work done lately... any chance you can regress this using the nightlys?
This is still happening with r18892
Regress using the nightlys, meaning going back through the nightlys and seeing where the problem first appears
The additional history entries come from the titles advertisements that are displayed in iframes.
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.
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.
*** Bug 12650 has been marked as a duplicate of this bug. ***
From duplicate: <rdar://problem/4921797>
(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.
Using the reduction, I regressed this further with the nightlies to the 17256-17272 range
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.
The reduction Mark posted way key - it was well understood and a fix was committed in r20813! Yay!