Community
Participate
Working Groups
I couldn't find an existing bug for this though it's been discussed ad nauseum. Some people prefer that some orion links (particularly the navigator) always open a new page vs. having to ctrl click. This should be a pref. The hard part is figuring out which links the pref applies to. Note there are some "links" like outliner, etc. which wouldn't open a new page even if the preference were set. Also note, in nav we try to style "navlinkonpage" vs "navlink" to distinguish to the user which links are ajaxy pseudo-page transitions and which are actually links to somewhere else. So maybe it's a matter of making the preference apply to the nav link "somewhere else" case. I could also see folks wanting *some* breadcrumb links to work this way. Not the ones that we scope with, but the ones in the editor that take you back to the nav.
Here is an argument for default-to-open-in-new-tab Orion pages are task-oriented. I open a page to work on a task. Thus if I click on a link that opens a new URL, I am expressing the desire to start a new task. What about the task I opened first? My click says nothing about that task. So think of the question "When should Orion automatically close a task-page?" I guess you might answer "only when the task is done". Since no Orion page I have used operates as a wizard, no task is done, ergo no auto-close should be used. If the URL path changes then it should appear in new page. An option to auto-close tasks (open in same tab) would be ok ;-).
I use Coda on my macbook. When I select a file from the nagivation area there, it opens that file in a new tab. I use Eclipse on my PC. When I open a file from the navigation area there, it opens that file in a new tab. I know neither of those tools are web based, but I don't believe this user experince should differ because we're opening hyperlinks on a web page. I think a user would expect the same behavior that they're used to on other editors. Especially when building web apps, where a page is the result of content mixed from HTML, CSS, and JS files. (In reply to comment #0) > I couldn't find an existing bug for this though it's been discussed ad nauseum. > Some people prefer that some orion links (particularly the navigator) always > open a new page vs. having to ctrl click. > This should be a pref. The hard part is figuring out which links the pref > applies to. > Note there are some "links" like outliner, etc. which wouldn't open a new page > even if the preference were set. > Also note, in nav we try to style "navlinkonpage" vs "navlink" to distinguish > to the user which links are ajaxy pseudo-page transitions and which are > actually links to somewhere else. So maybe it's a matter of making the > preference apply to the nav link "somewhere else" case. > I could also see folks wanting *some* breadcrumb links to work this way. Not > the ones that we scope with, but the ones in the editor that take you back to > the nav.
There is no mechanism to "Open In new Tab" for Search input
(In reply to comment #0) > Also note, in nav we try to style "navlinkonpage" vs "navlink" to distinguish > to the user which links are ajaxy pseudo-page transitions and which are > actually links to somewhere else. So maybe it's a matter of making the > preference apply to the nav link "somewhere else" case. Anton and I discussed marking the links with a class so that we know the ones that are retargetable. The class is probably just an empty marker for now, since the way links render is slightly different in different situations (top banner links only underline on hover, command and nav links always underline, etc.). Anton, besides the navigator links, the places that would add this class to links: - core/web/orion/globalCommands.js line 422 (primary nav links) - core/web/orion/commands.js * line 1135 (command links) * line 1102 and 1105 (menu links) - core/web/orion/commonHTMLFragments.js line 57 (footer links, note we already retarget those to a new tab, they should probably just behave like the rest) - core/web/orion/searchClient.js line 236 (open resource links, search result links) I was thinking that you could have common code that just looks for the class and changes the target. There may be some timing issues with dom elements rendered asynchronously by the page, so we probably have to have the pages make some explicit call in order to set it up, since they know when they are done... We also want to be able to read the preference from somewhere. For example: core/web/orion/commands.js line 258 is doing window open for key bindings, it should probably check the value of the preference
This is unmanageable for all links in all pages. It is probably unwise too for performance reasons for the client to consult the server or local storage each time a page request is made, to check if it should be opened in a new tab or not. When I made the proposal for this feature it was with navigation in mind. I think I've programmed enough for navigation. We can play it by ear for other link types.
