Closed Bug 123415 Opened 23 years ago Closed 22 years ago

clarify wording of "control+enter in urlbar" pref to avoid confusion about opening windows vs tabs

Categories

(SeaMonkey :: Tabbed Browser, defect)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
mozilla1.0.1

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

(Whiteboard: [adt3])

spun of bug 105537 comment 79 issue (1): as it stands the the "Control+Enter in the URL bar" pref is misleading since it is in a section titled "Open tabs instead of windows." the incorrect implication being that, when this pref is off [default setting, btw], hitting Control+enter [or command+enter on mac] would open the url in a new window --which actually does not happen! i have filed an enhancement, bug 123414, asking whether or not we should implement ctrl+enter/cmd+enter to open the url in a new window. however, whether or not it's implemented, we really need to clarify this particular tabbed browser pref!
Keywords: nsbeta1
My feeling is that it should be implemented so that {Ctrl,Cmd}-Enter opens a new WINDOW if tabbed browsing if OFF and in a new TAB if tabbed browsing is ON. When tabbed browsing is enabled Tabs take the place of Windows, IMHO, and the prefs should reflect that. If tabs are enabled then a new window should only be opened explicitly by the user via File->New Navigator Window or Ctrl-N. Yes, the wording and location of the (UI) pref is misleading. How about moving it up a level, to Preferences->Navigator, and labelling it, "Ctrl-Enter opens new Window (Tab if Tabbed Browsing enabled)" For the pref itself how about something like "browser.display.ctrl_enter_opens_new", true|false
On second thoughts, do we actually need a pref at all? As long as Enter opens a URL in the current window (or tab if they enabled) then Ctrl-Enter should always open in a new tab/window. What is the point of having a pref to enable/disable Ctrl-Enter? If users always want to use the current tab/window, just don't press Ctrl!
over to jatin for phrasing ideas...
Assignee: jaggernaut → jatin
Summary: clarify "control+enter in urlbar" pref to avoid confusion about opening windows vs tabs → clarify wording of "control+enter in urlbar" pref to avoid confusion about opening windows vs tabs
Does Ctrl+Enter have any other usage? Ctrl+Enter doesn't do anything on my trunk build.
I think the idea behind the pref was to let the user choose whether accel+enter opens in a new tab or in a new window, exactly as indicated. We will need to fix the implementation to actually open a new window.
Ctrl+Enter is broken on Windows due to some bug on that platform. I'm wondering if we should keep this in, or just make it a hidden feature which (for now) always opens a new tab on non-Windows platforms.
Based on Jag's comment, the sentence should read: "Ctrl+Enter in the Location Bar"
Note that ctrl != accel. If we want this to be accel-enter we should say so and make sure we follow the accel key pref.
This should be accel and not ctrl, imo.
Most users do not understand what "accel" is or means. Providing a specific keystroke would be more helpful, even if it means having a longer description that has each platform-specific keystroke.
This is worse, actually. The accell key pref has UI. We could create the text dynamically for the known possible access keys, I guess...
My comment was a reply to comment 8, where Boris correctly pointed out that we probably shouldn't hardcode this to "control" on the Mac, but rather use the "accel" definition as given for that platform. Part of that is that the UI will need to provide the correct text to go with it, not literally "accel".
So my proposal would be to have a properties file with strings corresponding to the various accel keys and then at runtime check the accel pref and use the corresponding string. I'm not sure how that will work on various platforms (does the Unix "control" pref value mean "control" or "command" on mac?).
That's where you can store the key names. I believe that on Mac control becomes Option, but I'm not sure. And of course we have to accomodate for the fact that accel can be both Alt and Control on Linux/Windows, based on some user pref.
actually, on mac the Command key corresponds to "accel". jatin, Command+Return [Control+Enter on linux and win32, except that win32 it's broken due to bug 50255] currently sends a mail message when you're in mail composition.
Thanks for the explanation. To further clarify the checkbox, I would suggest the following wording: Open a tab instead of window for: [x] a middle-click or (accel)+click on a web page link. [x] a new window opened by a web page [x] (accel)+Enter pressed in the Location Bar I know this suggestion goes beyond the "Ctrl+Enter" checkbox, but I feel it would make the whole preference more understandable.
Blocks: 128632
Reassigning -> jaggernaut@netscape.com for fixing
Assignee: jatin → jaggernaut
nsbeta1+ per Nav triage team, Nav3, ->1.0. We should do the easiest, lowest risk change possible (such as changing the wording or removing the checkbox) to bring tab pref UI in line with the way the feature works.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [nav3]
Target Milestone: --- → mozilla1.0
-> me since I've got bug 106398.
Assignee: jaggernaut → blaker
Jatin, I'm not sure I understand how your comment 17 fixes the issue reported here.
renominating. I don't think this is critical.
Keywords: nsbeta1+ → nsbeta1
nsbeta1+ per Nav triage team. This is the cool new feature, and will get more attention than most. Could someone else help with this?
Keywords: nsbeta1 → nsbeta1+
This is easy to do, I just need UE advice.
In the fourth checkbox, 'Control+click' should be changed to 'Command + click' for MacOS only. The last Control+Enter checkbox pref has no effect on any platform, and should just be removed until bug 123414 is fixed.
Peter: the last checkbox does work now (I have another bug about changing Ctrl+Click to Cmd+Click on Mac only that's already nsbeta1+) However, do we really need a pref? Ctrl+Enter doesn't currently do anything special if you don't have that checkbox checked, so maybe it should just always open a new tab. The only downside to that, I think, is that IE uses that as a command to prepend and append "www." and ".com", respectively, so our behavior might surprise any users who know that.
What bug was plussed for adding support for accel+Enter? If that is somehow already checked in and working in all cases then we could consider removing the pref, though I believe the original intent was that it open the URL in a new window when the pref was disabled. BTW, this bug sure seems like a dup of 106398, where LordPixel correctly points out that occurrences of Enter should be changed to Return on MacOS.
I think the code has been there for awhile, but when they fixed ctrl+enter generically (so that ctrl+enter would send mail in compose), this began working on Windows. Perhaps I have been looking at this bug the wrong way. Do we want to fix the wording to not suggest that ctrl+enter opens a new window, or do we want to open a new window on ctrl+enter? Either way is pretty simple; it looks like bug 123414 is for the implementation of ctrl+enter in new window.
Okay, cool. Comment #19 represents the Nav triage team's position. If the easiest/safest solution now means removing the pref and leaving the behavior intact, that'll do just fine.
converting nav3->adt3
Whiteboard: [nav3] → [adt3]
ok i think i agree with what's being said, let me reiterate what i think that is: remove the pref which says "ctrl+enter opens URL in tab instead of window", therefore ctrl+enter will always open a tab with the URL. if so, i feel that is a good choice because it is a new feature, reserved from the start for tabs. so there is no previous usage to overcome or reverse.
That's just the safe/expedient choice for MachV (since it already works that way), we can always add a pref to toggle opening in a new window/tab later.
Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to target milestone 1.0.1. Please confine your attentions to driving down our list of TM 1.0 bugs for beta. Better to help, debug, or test one of them than fix one of these.
Target Milestone: mozilla1.0 → mozilla1.0.1
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
hrm, well, i revisited this by testing with today's bits... when i have this pref turned on, it doesn't appear to work on Mac. *sigh* anyhow, filed bug 141578.
Keywords: relnote
nominating.
Keywords: nsbeta1- → nsbeta1
Nav triage team: nsbeta1+/adt3
QA Contact: sairuh → pmac
nsbeta1+/adt3 per the nav triage team.
Keywords: nsbeta1 → nsbeta1+
Control+enter in URL bar can open in a new window, so the wording is no longer a problem. Note, it should say Return instead of Enter on Mac but that's the subject of bug 106398.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
zap
Status: RESOLVED → VERIFIED
Keywords: relnote
QA Contact: pmac → sairuh
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.