Closed Bug 465284 Opened 11 years ago Closed 10 years ago
Open link in new tab
No description provided.
Sounds like an entry in a context-sensitive menu (tap and hold) on a link to me.
I'm not a big fan of piling up stuff in context menus. Would it make more sense to just allow you to hold a key for this, or do we really need this?
have a look at the suggested CSM commands and availability from here https://wiki.mozilla.org/Mobile/UI/Designs/TouchScreen/workingUI/CSM
Agreed about not just piling stuff into context-sensitive menus, but this is one of the primary uses, in my mind, for a CSM here. We could use a key, too, but I think we need to design for a keyboard-not-deployed scenario.
I was going to open a bug on this but I saw this one. We need a way to open a link in a new tab for usability. Currently, I have to open a new tab from scratch and then browse to the site where I wanted to open a new tab and find the link in question. Compared to Firefox, were people open new tabs from links as a primary use, this is a bit clunky.
I tend to agree with Al on this issue. We need to have some method for this, but I think we can prioritize this down. Using a CSM seems like the right approach here as it doesn't restrict to devices without keys (like the n800).
In my opinion there are different ways to solve this issue: 1.) Show a menu layer every time I tip on a link. A good example for this is: http://songza.com/ a.: click on "listen to this playlist now" b.: click on a song/track --> Result is an context menu. For fennec it could include "open link in a new tab" and maybe other stuff. 2.) My favorite is the simple tip on the link for a long time and it will open it in a new tab. No context menu. Just tip and hold (~ 2 seconds). A combination of 1.) and 2.) should be possible too... 3.) First tip on an area in one of the menus (e.g. the tab bar or the sidebar on the right side of the screen...) and then tip on a link.
While dogfooding Fennec, I find myself wanting this feature a lot.
tracking-fennec: --- → ?
We could do this simply on the n900/n810 by using the shift key as a modifier on click.
If we were going to use a keyboard key as a secondary mechanism (even while we sort out what the primary mechanism is), it's worth looking at Firefox on other platforms. Mac: Cmd-Click Win: Ctrl-Click Linux: Ctrl-Click Which is apparently <accel>-click. There's a Ctrl key on the n900's keyboard -- maybe it makes sense to use that one?
Shift-Click has been used to open in a new window for a while, at least on Windows. I'd be happy with either combination, since we don't actually support additional Fennec windows.
CTRL+click sounds reasonable, since we are opening a new tab. Also multi-key combinations are very hard to do on the devices.
On the N810 CTRL is on the right. If you're right-handed it's much easier to use Fn which is on the left - it's under your thumb. Make it configurable? Use either?
Fn is a sticky key though, so I see that as an accident waiting to happen.
CTRL+click will be our Fennec 1.0 approach. No shortcut key is very discoverable, so consistency with desktop Firefox is helpful in this case. Also, shortcut keys should not be our primary method, but due to time constraints, it might be the only method for Fennec 1.0
Priority: -- → P1
Ben - are you working on this?
Yes, I'm trying to get a patch ready before I head on my honeymoon.
This is the first part of the fix -- get shift/ctrl/alt/meta status passed into content when we send a click event
Assignee: nobody → combee
Status: NEW → ASSIGNED
Attachment #407603 - Flags: review?(mark.finkle)
This is a full patch. We're not adding click handler to content, just doing it before we'd dispatch to content. It worked on planet.mozilla.com, and ctrl-click on non-links did nothing. Right now, it opens in new tab with no UI indicating the change, could easily modify to open in background if we could popup notification about new tab being created.
Comment on attachment 407695 [details] [diff] [review] Full patch for ctrl-click opening new tab Nice, simple patch. Before I r+, I want to talk to Madhava about the background vs. foreground issue (I'm leaning on background, but we'll see) I might throw some explicit element type checks in the getHrefForElement method too. Just in case some yahoo puts "href" on atypical elements. Thanks and have fun on the honeymoon!
Background. That's what we do on the desktop, and I think that makes sense here too.
I'll adjust code for opening in background and also update the href detection code. Not sure how to do the notifications yet, I'll leave that for someone else.
I believe that the notification for background tabs happens because of existing code? But, then, I believe a lot of things.
(In reply to comment #24) > I believe that the notification for background tabs happens because of existing > code? But, then, I believe a lot of things. You are correct. Popup should just work.
Attachment #407695 - Flags: review?(mark.finkle) → review+
pushed: https://hg.mozilla.org/mobile-browser/rev/f24c33089482 with changes for opening in background and matching FF link-find code
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → B5
NOTE: Bug 524123 means the opened tab does not render correctly. Not related to this bug/patch
Depends on: 524123
Target Milestone: B5 → ---
verified FIXED on builds: Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:1.9.2b1pre) Gecko/20091026 Fennec/1.0b5pre and Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.3a1pre) Gecko/20091026 Fennec/1.0b5pre
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.