Bug 24472 - history.length does not return number of elements in history list
Summary: history.length does not return number of elements in history list
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 525.x (Safari 3.2)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Darin Fisher (:fishd, Google)
Keywords: InRadar
: 14499 (view as bug list)
Depends on:
Reported: 2009-03-09 15:56 PDT by Manuel Deschamps
Modified: 2010-01-19 11:26 PST (History)
6 users (show)

See Also:

v1 patch (6.31 KB, patch)
2010-01-15 12:51 PST, Darin Fisher (:fishd, Google)
beidson: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Manuel Deschamps 2009-03-09 15:56:49 PDT
This seems like it is a bug in our implementation.  The behavior (previously unspecified) is now spec in http://www.whatwg.org/specs/web-apps/current-work/#dom-history-length Please file a bug.


On Mar 9, 2009, at 3:41 PM, Manuel Deschamps wrote:

Hello guys,

It is been while!.. I had a question for you about the History object. 

In IE and Firefox, history.length returns the number of elements in the history list while in Safari and Opera the same property returns the "index" of the page in the history list.


1) launch browser X
2) go to www.apple.com
3) then go to www.yahoo.com
4) click the back button
5) type javascript:alert(history.length)

in IE,FF  the value is 2,   in Safari 3/4 the value is 1

So my question is, is this a bug in Safari or IE and FF are not following the standard correctly? :)

Manuel Deschamps | Software Engineer - Yahoo! Mail
tel: 408-336-0493 | manueldr@yahoo-inc.com
Comment 1 Brady Eidson 2009-03-11 10:32:07 PDT
Comment 2 Darin Fisher (:fishd, Google) 2010-01-13 11:16:35 PST
Confirming.  This is a bug per spec, and it seems like WebKit really should match IE and FF here.  I'm happy to write a patch for this if there are no objections to changing WebKit's behavior.
Comment 3 Brady Eidson 2010-01-13 11:20:18 PST
No brainer.  Do it.
Comment 4 Darin Fisher (:fishd, Google) 2010-01-15 12:51:37 PST
Created attachment 46703 [details]
v1 patch
Comment 5 Brady Eidson 2010-01-15 12:59:30 PST
Comment on attachment 46703 [details]
v1 patch

Comment 6 Darin Fisher (:fishd, Google) 2010-01-15 14:09:03 PST
Landed as http://trac.webkit.org/changeset/53346
Comment 7 Eric Seidel (no email) 2010-01-15 14:47:18 PST
Looks like this is failing on Leopard:

I think you already mentioned that in IRC, but wanted to record it here in case you hadn't noticed.
Comment 8 Eric Seidel (no email) 2010-01-15 15:19:29 PST
Darin is not online or in his office.  I'm going to roll out this change to fix the builders.  He can roll it back in with the test fixed.
Comment 9 Eric Seidel (no email) 2010-01-15 15:31:36 PST
Darin disabled the test in http://trac.webkit.org/changeset/53348 so the builders should roll green.
Comment 10 Alexey Proskuryakov 2010-01-18 23:54:46 PST
*** Bug 14499 has been marked as a duplicate of this bug. ***
Comment 11 Alexey Proskuryakov 2010-01-19 00:02:02 PST
It doesn't look like the patch was rolled out, after all. And the test has been fixed, too. Does the bug need to remain open for some reason?
Comment 12 Eric Seidel (no email) 2010-01-19 00:12:39 PST
This bug should be updated with the revision of the fix, but certainly doesn't need to stay open on my account. :)
Comment 13 Darin Fisher (:fishd, Google) 2010-01-19 11:26:19 PST
Yeah, I fixed the test.  See https://bugs.webkit.org/show_bug.cgi?id=33749 for details.