Bugzilla – Full Text Bug Listing
| Summary: | [client] navigating with the outliner affects browser history | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | john.arthorne, pmuellr, simon_kaegi |
| Version: | 0.2 | ||
| Target Milestone: | 0.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 334195 | ||
| Bug Blocks: | |||
|
Description
Susan McCourt
another issue with browser history concerns staying on a page when it's dirty. If you change the hash such that you are trying to edit a new file, and it's dirty, you get a dialog asking if you are sure you want to navigate away. If you answer no, then from the user's perspective, we never left the page and the browser history should remain the same. But under the covers we actually did navigate, prompt the user, decide not to load the new file, and set the hash back to what it was. So the history actually changes. This becomes confusing especially if you were using browser history and that's what caused the dirty prompt. For example, you push forward, you get a dirty prompt, you say don't navigate, now there is no more forward history (because you've moved forward and then again forward to the old file). i'd like to look at this as part of bug 334195. We need to decide who among the editor, the saveable service, and the editorContainer should know about our use of hashes, line numbers, etc. I know I personally found this annoying. Since there is no other way to get back to the Navigator from the editor page, I found myself hitting back 20-30 times to get out of the editor (or manually fiddling with the URL in the address bar). (In reply to comment #3) > I know I personally found this annoying. Since there is no other way to get > back to the Navigator from the editor page, I found myself hitting back 20-30 > times to get out of the editor (or manually fiddling with the URL in the > address bar). agree it's annoying. But you can get back to the navigator from the editor page by clicking the eclipse (home) image. (In reply to comment #4) > agree it's annoying. But you can get back to the navigator from the editor > page by clicking the eclipse (home) image. Cool, didn't know that! (In reply to comment #3) > I know I personally found this annoying. Since there is no other way to get > back to the Navigator from the editor page, I found myself hitting back 20-30 > times to get out of the editor (or manually fiddling with the URL in the > address bar). Concur, annoying. I thought this was a fairly solveable problem. I think the push/pop state stuff in the most recent versions of "HTML5" capable browsers helped, but I seem to remember hearing about problems. Of course, I think the fact that we are actually reloading pages is the main problem. DO NOT WANT. I'd like a single window open that doesn't reload the page; updates the page dynamically. Ideally, I would end up using Fluid or something to create a single-site-browser, and remove the navigation controls altogether. Is there already an open bug on this issue (single vs multi-tab/page/window)? I didn't see one. (In reply to comment #6) > (In reply to comment #3) > > I know I personally found this annoying. Since there is no other way to get > > back to the Navigator from the editor page, I found myself hitting back 20-30 > > times to get out of the editor (or manually fiddling with the URL in the > > address bar). > > Concur, annoying. I thought this was a fairly solveable problem. I think the > push/pop state stuff in the most recent versions of "HTML5" capable browsers > helped, but I seem to remember hearing about problems. It should be solvable, we are using dojo hash. We aren't reloading for outlining, we are catching hashchange and using js to manipulate the editor selection based on the line number in the url. When hashing, dojo lets the client determine how browser history is affected. So this is simply a bug. > > Of course, I think the fact that we are actually reloading pages is the main > problem. DO NOT WANT. I'd like a single window open that doesn't reload the > page; updates the page dynamically. Ideally, I would end up using Fluid or > something to create a single-site-browser, and remove the navigation controls > altogether. Is there already an open bug on this issue (single vs > multi-tab/page/window)? I didn't see one. I'm not sure what you are suggesting here, so could you open a bug and clarify? By design we are trying to contribute content that integrates nicely with other sites used for js development workflows (bug trackers, doc, etc.) We aren't an all-inclusive IDE site, but rather pages/tasks that you can integrate with your other sites for an in-browser workflow. We see the user controlling primary nav of their workflow through the tabs. It would help if you opened a bug to describe what you are imagining as a SSB workflow. (In reply to comment #7) > (In reply to comment #6) > > Of course, I think the fact that we are actually reloading pages is the main > > problem. DO NOT WANT. I'd like a single window open that doesn't reload the > > page; updates the page dynamically. Ideally, I would end up using Fluid or > > something to create a single-site-browser, and remove the navigation controls > > altogether. Is there already an open bug on this issue (single vs > > multi-tab/page/window)? I didn't see one. > > I'm not sure what you are suggesting here, so could you open a bug and clarify? > By design we are trying to contribute content that integrates nicely with > other sites used for js development workflows (bug trackers, doc, etc.) We > aren't an all-inclusive IDE site, but rather pages/tasks that you can integrate > with your other sites for an in-browser workflow. We see the user controlling > primary nav of their workflow through the tabs. It would help if you opened a > bug to describe what you are imagining as a SSB workflow. Perhaps I'm setting my sights a bit high, for the moment. I'm thinking you're building an IDE. But your comment suggests you're just building "pages/tasks" that would be embedded in other web applications. Fair enough. So the page reloading is a byproduct of the fact that the current drop DOES actually provide kind of an IDE - a "just enough IDE" - but it just happens to not be a single-page IDE like I suggested. You could have just as easily built the "just enough IDE" bits in the current drop that were single-page style instead of using traditional page reloading. The "just enough IDE" isn't the thing to be focusing on, which I did in the paragraph above. About right? (In reply to comment #8) > Perhaps I'm setting my sights a bit high, for the moment. I'm thinking you're > building an IDE. But your comment suggests you're just building "pages/tasks" > that would be embedded in other web applications. > > Fair enough. So the page reloading is a byproduct of the fact that the current > drop DOES actually provide kind of an IDE - a "just enough IDE" - but it just > happens to not be a single-page IDE like I suggested. You could have just as > easily built the "just enough IDE" bits in the current drop that were > single-page style instead of using traditional page reloading. The "just > enough IDE" isn't the thing to be focusing on, which I did in the paragraph > above. > > About right? Yeah, there's some decent verbage around this concept here: http://wiki.eclipse.org/Orion/Project_mission_statement the thought being that we simply will not be able to keep up with web-pace for developer workflows so we want to provide important pieces such as code editing, server API for eclipse workspaces, navigation of remote workspaces, etc. And because we assume that you'll be using other sites in your workflows, we aren't trying to consolidate ours in a single page. So we're trying to focus on lightweight pages rather than a single web page. At least for now. (In reply to comment #1) > another issue with browser history concerns staying on a page when it's dirty. The problem described in comment #1 is now fixed by virtue of fixing bug 334195. So the remaining issue in this bug is that the outliner affects browser history. There's nothing all that special we are doing to cause this. - the outliner renders anchor tags whose links contain the line number - we use the hash to move the editor accordingly - we never programmatically set the hash, so we don't get to decide whether the hash change is entered in browser history. To fix this we would have to either: - stop using anchor tags and instead do a programmatic dojo.hash that doesn't alter the history. But this means we can't offer "open in tab" and other normal link context menu actions. - find a way to alter the history after the fact. Simon, any advice here? This is the main place I know of in the UI that "just letting links do their thing" isn't satisfying. Maybe use history.replaceState when we recognize the resource selection is the same as the current but line number or whatever else is different. we were doing some of that (through dojo's hash API which as a true/false for replace state) but that seemed to blow away the entire history state. (for example bug 336261 comment 6) We don't want to lose all previous history. perhaps Dojo 1.6 handles this better. I'll look closer in M8. (In reply to comment #11) > This is the main place I know of in the UI that "just letting links do their > thing" isn't satisfying. Bug 344476 finally gave another case where "letting the link do its thing" also produced a bogus result. I've changed the outliner to use the selection service for navigation of the editor, unless the user uses ctrl-click to open a new page. Note this means that you won't see the browser address change to add the "?line=n" URL. We now treat navigating with the outliner the same as, say, using Ctrl-L to goto line. The "?line=n" URL's are still supported, so if the user were to navigate the editor by adding or updating line info in the browser bar URL, it will work as before, and will be in the browser history, which makes sense. More implementation detail is in bug 344476. |