Bugzilla – Full Text Bug Listing
| Summary: | BrowserHistoryListener not always notified | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Elias Volanakis <elias> | ||||||
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | claudio.guglielmo, ivan, rsternberg | ||||||
| Version: | 1.5 | ||||||||
| Target Milestone: | 2.0 M4 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Mac OS X | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Elias Volanakis
Elias, could you try to reproduce it with our online Examples Demo: http://rap.eclipsesource.com/rapdemo/examples#dialog The URL will navigate you to the Dialogs page. Valid ids are also #canvas, #tableviewer... Did you type the URL manually? In Chrome there is preloader feature that load the page when you type. Maybe it loads the page before you finish the URL with the anchor!? Apparently, a BrowserHistoryListener is only notified for *known* entries, i.e. you have to call IBrowserHistory#createEntry() with the id used as #anchor before, see History.js, line 248. I was not aware of this restriction and it's not clear when it has been introduced. It seems that the idea behind it was that a "history" is only used to restore a previous state. The name "history" maybe badly chosen, we could think about alternatives in 2.0. Anyway I think that we should remove this restriction to allow history listeners to be notified for random entries as this is the only way to support navigation within an Ajax application. Fixed in master with commit f7e19ae28127543f8adac7fa287d23520effdb35. Created attachment 224044 [details]
Patch for 1.5 maintenance branch
I think that this patch is safe for 1.5 maintenance branch.
(In reply to comment #4) > I think that this patch is safe for 1.5 maintenance branch. Even if it's safe, the fix changes the behavior of the browser history. It's not a critical bug fix, so I'd tend to keep it out of the service release. Even with the patch, the problem still exists. Navigating to a 'unregistered' anchor, still requires the user to enter it twice: http://127.0.0.1:8080/rap#foo ENTER http://127.0.0.1:8080/rap#foo ENTER Navigating to a 'registered' anchor (i.e. for which RWT.getBrowserHistory().createEntry("foo", "foo") has been called), works by entering it just once: http://127.0.0.1:8080/rap#foo ENTER The same behavior should occur for 'unregistered' anchors. Test with both RAP 1.5.1 + patch and RAP 2.0.M3 (In reply to comment #6) > Even with the patch, the problem still exists. > > Navigating to a 'unregistered' anchor, still requires the user to enter it > twice: > > http://127.0.0.1:8080/rap#foo ENTER > http://127.0.0.1:8080/rap#foo ENTER > > Navigating to a 'registered' anchor (i.e. for which > RWT.getBrowserHistory().createEntry("foo", "foo") has been called), works by > entering it just once: > > http://127.0.0.1:8080/rap#foo ENTER > > The same behavior should occur for 'unregistered' anchors. > > Test with both RAP 1.5.1 + patch and RAP 2.0.M3 Elias, this issue is fixed in master, not in 2.0M3. Will be part of the 4-th milestone. About the patch... did you rebuild the client.js [1] after the patch? [1] https://github.com/ralfstx/rap-clientbuilder Thanks Ivan. Setting to RESOLVED. *** Bug 396400 has been marked as a duplicate of this bug. *** Removing the sr152 flag, as suggested in comment 5. |