Bug 21605 - Support for HTML5 "hashchange" event
: Support for HTML5 "hashchange" event
: WebKit
Page Loading
: 528+ (Nightly build)
: All All
: P2 Enhancement
Assigned To:
: InRadar
  Show dependency treegraph
Reported: 2008-10-14 16:38 PST by
Modified: 2009-08-07 08:37 PST (History)

Fix + Layout Test (14.22 KB, patch)
2009-08-06 22:31 PST, Brady Eidson
darin: review+
Review Patch | Details | Formatted Diff | Diff


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

Description From 2008-10-14 16:38:27 PST
Please consider adding support for observing .hash change in Location object.

More info:
http://www.whatwg.org/specs/web-apps/current-work/#history-traversal (6th bullet)
http://ejohn.org/blog/javascript-in-internet-explorer-8/ (HTML 5: window.location.hash)
------- Comment #1 From 2008-11-23 16:42:49 PST -------
Confirming the bug and moving its severity to enhancement.
------- Comment #2 From 2009-07-03 07:53:21 PST -------
Firefox has added support for "hashchange" event in latest nightly


Is this going to be implemented soon in WebKit?
------- Comment #3 From 2009-07-17 00:22:40 PST -------
I am interested in implementing this. I'll probably need to make use of the tests from the Firefox implementation and/or play with IE8 a bit since there seems to be some trickiness.

I expect the WebKit code part of it should not be too hard.
------- Comment #4 From 2009-08-06 22:24:42 PST -------
This is in radar as part of <rdar://problem/5838863>

Assigning to myself as I have a patch for this.

It implements the behavior as specc'ed.  Firefox doesn't seem to have any surprises the spec didn't cover.   I can't test IE8 but the event itself wasn't too crazy complex.
------- Comment #5 From 2009-08-06 22:31:04 PST -------
Created an attachment (id=34251) [details]
Fix + Layout Test
------- Comment #6 From 2009-08-07 07:07:41 PST -------
(From update of attachment 34251 [details])
> +    HashChangeEventTask(PassRefPtr<Document> document)
> +    : m_document(document)
> +    {
> +        ASSERT(m_document);
> +    }

We normally indent that one tab stop.

> +    if (equalIgnoringRef(url, m_URL) && !equalIgnoringNullity(url.ref(), m_URL.ref())) {
> +        Document* currentDocument = frame()->document();
> +        currentDocument->postTask(HashChangeEventTask::create(currentDocument));
> +    }

If equalIgnoringRef(url, m_URL) ever false here?

------- Comment #7 From 2009-08-07 08:37:45 PST -------
Fixed the style.  

I *think* the URLs should always be equalIgnoringRef().  I added an ASSERT then checked in, not thinking it through because it's too early and I haven't had enough coffee yet.

I'm running the layout tests again post-ASSERT and hopefully it won't be firing all the time for some case we never thought of.  If it's a problem I'll remove it.

Sending        LayoutTests/ChangeLog
Adding         LayoutTests/fast/loader/hashchange-event-expected.txt
Adding         LayoutTests/fast/loader/hashchange-event.html
Sending        WebCore/ChangeLog
Sending        WebCore/dom/EventNames.h
Sending        WebCore/html/HTMLAttributeNames.in
Sending        WebCore/html/HTMLBodyElement.cpp
Sending        WebCore/html/HTMLFrameSetElement.cpp
Sending        WebCore/loader/FrameLoader.cpp
Sending        WebCore/platform/text/PlatformString.h
Sending        WebCore/platform/text/StringImpl.cpp
Sending        WebCore/platform/text/StringImpl.h
Transmitting file data ............
Committed revision 46892.