[patch][ccla] dojo.hash sometimes fires on its own hash changes

[dfabulich]

Open the attached hash-bug.html page. Its onload function subscribes to the /dojo/hashchange topic and fails if it is fired, and then uses dojo.hash to set the hash fragment.

Expected: The document should say "PASS"; the hashchange topic should not fire unless the user modifies the hash fragment.

Actual: On FF36 and GC7, the document says "FAIL", because the browser's native "onhashchange" event fires even on programmatic changes.

On IE6/7, the test passes, because _pollLocation in hash.js checks to see if the location has changed relative to its recently set value.

The patch is a three-line patch to configure dojo.hash to call _pollLocation when the native onhashchange event fires, (which will check the hash value against the _recentHash), instead of blindly calling _dispatchEvent to fire the event.

[dfabulich]

hash-bug.html demonstration

[dfabulich]

patch to fix the problem

[Rob Retchless]

This is working as designed. /jazz/hashchange subscribers should get notified whenever the hash changes (in alignment with the onhashchange event), whether it's through programmatic means or not. dojo.hash("foo") should publish the event to all subscribers, unless the hash was already foo.

Your test case seems to highlight another issue though. The events don't seem to get published ever in XD dojo in IE6/7. The hashchange support for IE6/7 uses a same-origin hidden iframe to trick the browser into storing back history states. This iframe ends up being ​http://ajax.googleapis.com/ajax/libs/dojo/1.5.0/dojo/resources/blank.html?foo in XD mode, which is different origin. Not sure how to solve that...

[Rob Retchless]

I did some research. Turns out the XD issue is documented under "Caveats and Gotchas" on the Cross-Domain Dojo docs: ​http://docs.dojocampus.org/quickstart/cross-domain

I have updated the dojo.hash docs to point this out: ​http://docs.dojocampus.org/dojo/hash

This can be resolved.