Opened 16 years ago

Closed 15 years ago

#907 closed enhancement (wontfix)

Better bookmarks handling

Reported by: [email protected] Owned by: James Burke
Priority: high Milestone: 0.9
Component: Core Version: 0.3
Keywords: Cc: [email protected]
Blocked By: Blocking:


I've got problem with proper handling of page bookmarks. I'm using dojo.undo.browser.addToHistory with custom changeUrl property.

Dojo is not handling following scenario:

  1. User enters our page, and decide to bookmark page with link:


  1. User enters our page in the future, clicks in bookmark page.html#link123 (when he is still at our page) and we can't handle this content call with current dojo.undo.browser behaviour because only window.location.hash has changed without reloading page.

I think that dojo.undo.browser should detect change of hash, and if it isn't forward or back button trigger it should trigger some registered callback function for handling bookmarks.

Change History (3)

comment:1 Changed 16 years ago by James Burke

Owner: changed from anonymous to James Burke

comment:2 Changed 15 years ago by dylan

Milestone: 0.40.5

comment:3 Changed 15 years ago by James Burke

Cc: [email protected] added
Resolution: wontfix
Status: newclosed

After doing a fix for #908, it became clearer to me that I'm not sure we should support this. If you are using a logical name for the changeUrl parameter, in this case #link123, then I believe this should indicate that the web application has a certain logical state for #link123. That state should not be different than if the user clicks on a bookmark or clicks on a link/button that goes to that logical state.

This also maps what browsers do for multiple sequential user actions for the same fragment identifier -- they don't reload the page because the state has not changed.

Therefore, I will close the bug as wontfix, but please feel free post back to this bug with reasons to reconsider.

Note: See TracTickets for help on using tickets.