Closed
Bug 105537
Opened 23 years ago
Closed 22 years ago
control+enter in url bar firing for just enter
Categories
(SeaMonkey :: Tabbed Browser, defect, P1)
SeaMonkey
Tabbed Browser
Tracking
(Not tracked)
VERIFIED
WORKSFORME
mozilla0.9.9
People
(Reporter: jmd, Assigned: jag+mozilla)
References
Details
Attachments
(1 obsolete file)
I turned on the pref: new windows open for ctrl+enter in the URL bar. Now just entering any URL and hitting enter opens a new tab. I'm guessing UNIX only.
Comment 1•23 years ago
|
||
I also see this on Win98SE, moz trunk build 2001101803, so this isn't only UNIX, someone confirm please...
Comment 2•23 years ago
|
||
I just changed that preference and got same problem in build 2001102203 on win98
Comment 3•23 years ago
|
||
*** Bug 106899 has been marked as a duplicate of this bug. ***
Comment 4•23 years ago
|
||
also on winNT. Please change OS to "ALL". Also suggest more clear summary: <ENTER> in URL-bar opens URL in *new* TAB (should load URL in existing TAB)
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
Comment 5•23 years ago
|
||
The pref is also called: user_pref("browser.tabs.opentabfor.urlbar", true); While in the preferences the checkbox is labeled: "Control+Enter in the URL bar" This is (imo) misleading. Probably the pref should get a different name.
Comment 6•23 years ago
|
||
I would hope the intent is for Enter to open in existing tab, Ctrl+Enter to open in a new tab, but if so, I"m not sure whay any pref is required.
Reporter | ||
Comment 7•23 years ago
|
||
Peter: I think (if I'm wrong, it should be) the intent is, when the pref isn't enabled, ctrl+enter opens a new window, rather then the same as pressing enter. So it's really just another window-or-tab? pref. Otherwise, yes, you're right, it wouldn't be needed. While we're on the subject, the 'links in web page' and 'links in personal toolbar' prefs under tabbed browsing really shouldn't be seperate. Just call it [X] Middle-click or Accel-click of links. The other possibility is we kill all four of those very similar prefs in favor of something like this: [X] Open tabs instead of windows when possible. That would cover ctrl+enter, links, and target=_new. Do we really expect some users to only want SOME of those cases to be windows and SOME to be tabs?
Comment 8•23 years ago
|
||
*** Bug 107702 has been marked as a duplicate of this bug. ***
Comment 9•23 years ago
|
||
*** Bug 108022 has been marked as a duplicate of this bug. ***
Comment 10•23 years ago
|
||
*** Bug 108753 has been marked as a duplicate of this bug. ***
Comment 11•23 years ago
|
||
*** Bug 108861 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 12•23 years ago
|
||
*** Bug 108959 has been marked as a duplicate of this bug. ***
Comment 13•23 years ago
|
||
is this because Ctrl-J = Enter?
Comment 14•23 years ago
|
||
Does this work on Windows? Bug 50255 says that ctrl-Enter doesn't work on Windows (but does on Windows and Mac). You might want to check and see how mail is doing their key binding.
Comment 15•23 years ago
|
||
No it´s not working on Windows.
Comment 17•23 years ago
|
||
FYI, I actually prefer opening a new tab on enter, which seems to be consistent with the way that I work.
Comment 18•23 years ago
|
||
opening a new tab on enter is good, unless the current page is empty. Leaving the about:blank pages around is what I noticed ...
Comment 19•23 years ago
|
||
I disagree with Gabor; *I* don't like it, when everytime I change a tiny thing in the URL a new tab opens. Suppose your browsing BUGs on Mozilla and know the numbers. So I'd go to the first bug, and then I'd might change the bug id in the URL. Pressing enter would open a new tab. This is annoying for me.
Comment 20•23 years ago
|
||
So add another check box; one to enable opening a new tab from the URL bar, and another for which behavior (on for CTRL+Enter opens new tab, off for CTRL+Enter opens in the current window; or something similar.)
Comment 21•23 years ago
|
||
My $0.02: Tabs are equivalent to windows, entering a new URL + enter using windows opens the URL in the same window. This should be analagous in the tab world, enter opens in current tab, control-enter in a new tab. If the consensus is truly to flip-flop this, then it should be flip-flopped for the 'window' equivalent as well - I doubt if this will go over well. We need consistency above all else (even personal preference). Cheers.
Comment 22•23 years ago
|
||
*** Bug 111113 has been marked as a duplicate of this bug. ***
Comment 23•23 years ago
|
||
> opening a new tab on enter is good, unless the current page is empty. I agree with this. If Enter is changed to not open in a new tab, I'd like a pref to set it back to the current behavior, possibly excepting cases where the current tab is blank. > Tabs are equivalent to windows You're smoking crack. Windows are a whole different animal. It is not convenient to have a primary document (such as search results) in one window and open a dozen or more related documents each in its own window while reading it, then switch to the others each in turn while leaving the original open for reference. With windows, that would be an impossible pain, keeping everything straight, checking back to see whether each window has finished loading yet, and so on and so forth; with tabs, it is a very convenient workflow. People who say "windows and tabs are equivalent" invariably don't understand the benefits of tabs. They may be equivalent to the layout engine, but they are NOT equivalent to the user. If this behavior is changed, it should be a preference. Personally, I like it very much the way it is.
Comment 24•23 years ago
|
||
The experience needs to be consistent. <ENTER> should behave the same for windows and Tabs to give the user a consistent experience. It annoys the heck out of me that <ENTER> opens a new Tab. I agree that for some situations, opening a new tab is desirable (e.g. searches), but, more importantly, most regular users get confused when windows or Tabs start opening on them ("suddenly, the <Back> button doesn't work anymore"). I suggest that <ENTER> always loads the url in the *current* document, and CTRL+ENTER opens a *new* window or Tab. A preference to reverse *both* behaviours would be nice (but this should be the default). I think this discussion might need its own bug or a newsgroup thread - unless you all agree with my superior resoning ;)
Comment 25•23 years ago
|
||
I agree. For me, windows and tabs are very much equivalent. I use tabs very much, because it helps me to cut down on the number of open windows. Heck, I could even live with only one open window, as long as the tab handling is good - in fact, using Opera I live very, very well with only one open window. Maybe for some users it might be desirable to open new tabs when an url is entered, so the current behaviour might be a preference setting, but the way it is right now, annoys the heck out of me as well. I very often find myself typing a URL in the adress bar because I want to leave the current site, and if instead a new tab opens, this is just wastage for me, because I'd have to go back to the old tab and close it. The current way simply is a cumbersome workflow to me. But I'd also like it, if a <CTRL>+<ENTER> would open a new tab with the typed URL for the rare cases when I'd want that.
Comment 26•23 years ago
|
||
*** Bug 111583 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
There are certainly some inconsistencies in the tabbed browser - which I'd like to say at this point I like *very* much. This is for Mozilla 2001112203 Win98 My settings are : -Open tabs instead of windows for- [x] Middle-click or control-click of links in a Web page [ ] Windows opened by the Web page [x] Middle-click or control-click of bookmarks and personal toolbar items [ ] Control+Enter in the URL bar 1. Works as expected, if I click on a link it opens in the current tab. If I control-click it opens in a new tab. 2. Not sure exactly what is to be expected from this. Javascript opens new windows if this is set or not. Links with target="" also open new windows, which I'd expect to have been opened in a new tab. Can't comment on anything which happens on page load/unload because I've got prefs set to prevent that. 3. Control-click of bookmarks and personal toolbar items always opens in the current tab. 4. Control+Enter in the URL bar dosn't work. If the pref is set then pressing enter in URL bar opens new tab, if the pref is unset then pressing enter opens in the current tab. Control+Enter is always ignored. Personally I don't like Enter on it's own opening either a new window or a new tab, if I'm typing into the URL bar then it's pretty much understood that I'm finished with what I'm doing and want to replace the current tab. Control+Enter would certainly be useful if I'm typing a URL from a web page that isn't actually a link but I'd control-click if it was. Anyway, that's my views.
Comment 28•23 years ago
|
||
*** Bug 111725 has been marked as a duplicate of this bug. ***
Comment 29•23 years ago
|
||
You are almost right. What is really annoying is if you want to replace the page you are currently viewing with what you are typing in the urlbar. i.e. about:blank I have no need to keep that page open. Or if I am changing direction. Killing a tab is just annoying.
Comment 30•23 years ago
|
||
OK. I've seen people argue one way or another about how they would like the tabbed workflow to 'work'. And this is fine - whatever works for you should be supported. However, I haven't heard *anyone* argue in favor of an inconsistent interface between tabs and windows. So, I propose that the interface (whether enter or ctrl-enter) be made consistent between tabs and windows and that a preference be created to allow either of the proposed workflows (enter opens new tabs/windows, ctrl-enter opens new tabs/windows). Furthermore, I would suggest that the 'default' workflow be the same as the current workflow for windows, i.e. enter opens URL in current window. If anyone is vehemently opposed to this, let's hear it (and why).
Comment 31•23 years ago
|
||
My preference is to open in existing tab or window (which ever is your preference) on hitting enter, and open a new tab/window (which ever is your preference) on hitting ctrl-enter. I can see an argument for a key combination to open in the other one.
Comment 32•23 years ago
|
||
It's quite a pain. Mabey a radio box for O Use Ctrl+Enter to open in new tab O Use Enter to open in new tab O Never open typed addresses in new tab I'd say this should be fixed pretty soon.
Comment 33•23 years ago
|
||
I'ld rather see two combo box: When pressing enter on URL bar: Open in current tab Open in a new tab Open in a new window When pressing Ctrl+Enter on URL bar: same thing And why not: When pressing Alt+Enter (or Shift+Enter) on URL bar: same thing
Comment 34•23 years ago
|
||
Oh, that's a good idea!Make this a select box for <Nothing>/<Ctrl>/<Shift>/<Alt>/<Meta>+Enter. So, it should read (kinda): <Nothing> <Ctrl>When pressing <Shift> + Enter, open URLs in a new tab <Alt> <Meta> <Nothing> <Ctrl>When pressing <Shift> + Enter, open URLs in a new windows <Alt> <Meta>So I'd like to see two options. And both options should be enableable/disableble (ie. there needs to be a check box for turning the whole thing off). Further, Mozilla should check if the options conflict, ie. it's not legal to set <ctrl> for both options.
Comment 35•23 years ago
|
||
*** Bug 111893 has been marked as a duplicate of this bug. ***
Comment 36•23 years ago
|
||
*** Bug 111876 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 37•23 years ago
|
||
Enough of this. Enter will open in the current window always. The only thing that will be selectable is whether or not ctrl+enter does a new tab or new window. If you want anything else, wait for editable keybinds. Comments 17-35 have all been utter nonsense, take it to a newsgroup if you feel the need to ramble.
Comment 38•23 years ago
|
||
Considering the last 2 dups, bug 111893 (mine - sorry) & bug 111876, I thought I'd include this comment. Another symptom of the problem (new tab opens when Enter pressed in URL bar) is that the URL bar becomes blank.
Comment 39•23 years ago
|
||
Given the target milestone 1.01, could we consider backing out the UI for the pref until it's fixed? Seeing as it doesn't work.
Updated•23 years ago
|
QA Contact: blakeross → sairuh
Reporter | ||
Comment 40•23 years ago
|
||
This is targeted for 1.0.1, so the UI should be commented out for now.
Comment 41•23 years ago
|
||
*** Bug 113928 has been marked as a duplicate of this bug. ***
Comment 42•23 years ago
|
||
Related to this bug: Right-clicking on a URL link in mail reader never opens a new tab. If right-click is configured to open a new tab, then it should do so in Mail/News as well as in Navigator.
Comment 43•23 years ago
|
||
*** Bug 115117 has been marked as a duplicate of this bug. ***
Comment 44•23 years ago
|
||
No comments recently but this is still happening. Choose which way it should work and change the text to reflect that. In the present state is is confusing. Personally I would prefer ctrl+enter opens an url in a new tab, regular enter just changes the page in the same tab. I'm running build 2001121703 on Win32 (Win2k).
Comment 45•23 years ago
|
||
To pass the "can you face slashdot" test in 1.0, there shouldn't be any completely broken features. In this case, the "Control+Enter in URL bar" config preference for Tabbed Browsing is completely broken - it has no effect. So it would be best to remove the preference item or make it invisible if the bug won't be fixed by 1.0 P.S. IMO Enter should always open in the current window/tab.
Comment 46•23 years ago
|
||
"In this case, the "Control+Enter in URL bar" config preference for Tabbed Browsing is completely broken - it has no effect." But it does have an effect. If it is checked when I enter an url in the location bar and hit enter a new tab is opened up with that URL. That should happen if I had held down control and hit enter but it does it with just enter (as I understand the dialog box). If unchecked the URL I entered is open in the current tab.
Comment 47•23 years ago
|
||
okay, this is what i see using 2001.12.17 bits on winnt, mac x and linux: when the pref "control+enter in urlbar to open a new tab instead of new" is false [off, default]: * both win32 and linux: both Enter and Ctrl+Enter just result in reloading the page in the current browser window. no new window is opened. same with Mac, Return and Cmd+Return just reloaded the url, no new window. when the pref is true [on]: * both win32 and linux: Enter opens the url in a new tab * win32: Control+Enter does nothing, likely due to bug 50255 so adding blocker. * linux: Control+Enter opens the url in a new tab. question: was Control+Enter/Cmd+Return in the urlbar *ever* implemented to open a new browser window? or, is the fact that it doesn't work another bug?
Comment 48•23 years ago
|
||
Silly question: shouldn't Enter (without modifier) open in the current window&tab regardless of what the pref is set to? That doesn't match what sairuh saw even on linux.
Comment 49•23 years ago
|
||
This bug is about ENTER actually firing a CTRL+ENTER (open in *new* window or Tab), *regardless* of what the pref says. If you read the pref carefully, you'll see that it has absolutely *no bearing* on this bug either way (i.e., forget the pref). This bug should be renamed (for clarity sake) to: "ENTER is firing a CTRL+ENTER" - where the reporter is assuming that CTRL+ENTER should open a *new* Tab or window, and ENTER should load in *current* Tab or window (BTW, I strongly agree with this assuption). This, IMO, is the way it should be: ENTER - opens URL in *current* tab or window CTRL+ENTER - opens URL in *new* tab or window Whether current or new depends on whether CTRL+ENTER or just ENTER. Whether tab or window depends on the pref. Clear?
Comment 50•23 years ago
|
||
"Clear?" No. On Windows editing an URL in the location bar and hitting enter results in a reload with this preference NOT checked. With it checked it results in a new window being opened with the edited URL. On Linux I see the same thing. Except control+enter does the correct thing with this preference checked (except of course it also does this with only enter so the bug is still present). So my experience is the same as comment #47 which sums it up most excellently.
Comment 51•23 years ago
|
||
I wasn't aware that the tabbed browser pref may be the cause of this bug (if it is, sorry). The preference (tabbed browsing - open tabs instead of windows for CTRL+ENTER) should have exactly ZERO effect on what happens when hitting just the ENTER key (whether selected or not). Either you are talking about a different (new) bug, or this bug needs its summary renamed (suggestion: "Pref for tabbed browsing 'open tab for CTRL+ENTER' is inappropriately affecting ENTER-only behaviour"). BTW, I *always* have a tab showing (i.e., Hide tab when only one = deselected)
Reporter | ||
Comment 52•23 years ago
|
||
> Whether current or new depends on whether CTRL+ENTER or just ENTER.
Which begs the question, why is there a pref in the first place?
I'd like to see the four "Open tabs instead of windows for..." prefs changed to
a single "[ ] Prefer tabs over windows".
If it's checked, ctrl+enter pops a tab. If not, ctrl+enter pops a window. What's
the purpose of having ctrl+enter do the same as enter. If you don't like the
feature, don't hit control. It's obscene pref bloat.
Similarly, there's one pref for middle clicking a web page link, and a seperate
one for middle clicking a personal toolbar link. Who would want these to do
inconsistant things? (Of course, the other choice should be available in the
context menu.)
Comment 53•23 years ago
|
||
RE comment #52: >> Whether current or new depends on whether CTRL+ENTER or just ENTER. > Which begs the question, why is there a pref in the first place? Turbogeek, for the last time: The CTRL+ENTER versus ENTER issue is *completely separate* from the PREFS issue (which is Tab versus window). CTRL+ENTER and ENTER should *not* be doing the same thing!!! That's the whole point of this bug. The bug is causing crossover behaviour, but when fixed, there will be no crosover behaviour. They will once again be *completely separate* issues. If you want less prefs, file a new bug - but don't discuss it here, please.
Comment 54•23 years ago
|
||
*** Bug 116223 has been marked as a duplicate of this bug. ***
Comment 55•23 years ago
|
||
*** Bug 116528 has been marked as a duplicate of this bug. ***
Comment 56•23 years ago
|
||
The milestone is set to Mozilla 1.0.1. The bug is very annoying and, without Mozilla source code knowledge, I'd say that seems to be a "simple to resolve" problem. Any possibility to advance the milestone to 0.9.8, for example? :-) PS: I prefer the general consensus: <enter>: open the URL in the current window/tab. <control+enter>: open the URL a new window/tab.
Comment 57•23 years ago
|
||
*** Bug 117432 has been marked as a duplicate of this bug. ***
Comment 58•23 years ago
|
||
*** Bug 117536 has been marked as a duplicate of this bug. ***
Comment 59•23 years ago
|
||
I think that since the bug is annoying (it was annoying for me until I realized how to work it around) and we don't have much time until 1.0, maybe this checkbox should be commented out until the backend is fixed? There are _two_ problems with the checkbox: 1) The checkbox comment wrongly states assumes that only Ctrl-Enter is affected. 2) The group caption wrongly implies that Ctrl-Enter should open a window if the checkbox is unchecked. Neigther of those two bugs has a trivial fix (I believe). Removing the checkbox avoids user confusion but removes no features (opening a tab on Enter is not a feature). Implementation: Find pref-tabs.xul (I don't have the sources, I just unpacked the jars). Comment out checkbox with id="urlBar"
Comment 60•23 years ago
|
||
*** Bug 118072 has been marked as a duplicate of this bug. ***
Comment 61•23 years ago
|
||
I have the same problem on SuSE Linux 7.1 (kernel 2.2.18). In addition the URL bar is empty after loading the page. Some of the other options don't work, too (like control-click of bokmarks and personal toolbar items). Besides it would be cool to have other mappings like "alt+click" open in new window (= old control+click)...
Comment 62•23 years ago
|
||
This patch fixes the problem on Linux/Mac. With it applied, enter will load in existing tab, and ctrl-enter will load in new tab. On Windows, ctrl-enter and enter both act like enter (see bug 50255). So this patch would essentially make this pref inoperable on Windows, forcing the "old" behavior. Once bug 50255 is fixed, it should just start working. I feel that we would be no worse off on Windows with this patch and a lot better off on Linux/Mac. Reviews?
Comment 63•23 years ago
|
||
ccing hewitt since I hooked into the autocomplete code...
Comment 64•23 years ago
|
||
sr=hyatt. Let's escalate 50255 and make sure it's targeted pre-1.0.
Comment 65•23 years ago
|
||
Given that it looks like this bug will be resolved by opening a new URL on control+enter rather than enter, I've opened bug 119960 to request enabling opening a new tab on enter (optionally, ofcourse).
Comment 66•23 years ago
|
||
*** Bug 120555 has been marked as a duplicate of this bug. ***
Comment 67•23 years ago
|
||
Comment on attachment 64870 [details] [diff] [review] Patch to fix this on Linux/Mac (pending bug 50255) (i'm not fond of the string 'ctrlKey')
Attachment #64870 -
Flags: review+
Comment 68•23 years ago
|
||
taking this to check it in once tree reopens.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
Priority: -- → P1
Target Milestone: mozilla1.0.1 → mozilla0.9.9
Assignee | ||
Comment 69•23 years ago
|
||
Seems you had the wrong radio button selected. -> bzbarsky
Assignee: jaggernaut → bzbarsky
Reporter | ||
Comment 70•23 years ago
|
||
*** Bug 121222 has been marked as a duplicate of this bug. ***
Comment 71•23 years ago
|
||
checked into trunk
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 72•23 years ago
|
||
*** Bug 121635 has been marked as a duplicate of this bug. ***
Comment 73•23 years ago
|
||
boris, this doesn't work for me in build 1-24-03, w2k, I can hit ctrl+enter all I want and nothing happens with the checkbox in a checked-state. Enter of course, will load in the current tab like usual.
Comment 74•23 years ago
|
||
boris, sorry, stupid me, didn't read the obvious comment #62. As I see you haven't gotten windows patched. Doh!
Comment 75•23 years ago
|
||
*** Bug 121923 has been marked as a duplicate of this bug. ***
Comment 76•23 years ago
|
||
Boris, first of all thanks for fixing my pet peeve! I have a strange situation here. Both Linux nightlies 2002012706 and 2002012721, branch and trunk if I am not mistaken, work fine, however my CVS build from 2 hours ago still shows the problem.. I did make distclean just to make sure there was no cruft, but still the problem is present. This is what I have in my .mozconfig: ac_add_options --enable-optimize="-O4 -march=k6 -mcpu=k6" ac_add_options --enable-crypto ac_add_options --with-extensions=default,irc ac_add_options --disable-debug ac_add_options --disable-dtd-debug ac_add_options --disable-jsd ac_add_options --disable-ldap ac_add_options --disable-xprint ac_add_options --disable-logging ac_add_options --disable-mailnews ac_add_options --disable-tests ac_add_options --disable-accessibility ac_add_options --disable-bidi
Comment 77•23 years ago
|
||
try cvs diffing the relevant files? You likely have some sort of changes in your local tree....
Comment 78•22 years ago
|
||
I am unhappy with this patch. As timeless pointed out, it uses a hard-coded 'ctrl-key' which is wrong. I'd like to see this bug reopened and address that issue.
Comment 79•22 years ago
|
||
I'd be happy to do that provided that: 1) We change the wording of the pref to make it clear that it's not ctrl-enter that will trigger the tab opening but "accel-enter". What's that in user-speak? Or should we make the tab wording dynamic based on a string from a stringbundle and set it depending on what the accel key is? 2) Someone explains to me what the acceptable values of "ui.key.accelKey" are. I can set it to ctrl, alt, or meta. Can I set it to "A"? Does the mailnews "ctrl-enter" keybinding for sending a mail follow that pref? akkana? any help on this? reopning while we discuss this.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 80•22 years ago
|
||
Make the wording "dynamic" if the key can be different on different platforms. Implied user instructions in prefs and menus must not lie! So if a key is different on different platforms, then the strings have to change accordingly. (I'm assuming here that the meaning of "accel" is for all practical purposes fixed for each platform. If not, then where is the pref and isn't this feature-bloat?)
Comment 81•22 years ago
|
||
> I'm assuming here that the meaning of "accel" is for all practical purposes > fixed for each platform. It is not. > where is the pref Please read my post. "ui.key.accelKey". It's in the debug panel. > isn't this feature-bloat No, it's an absolute necessity on Unix to keep ctrl-keybindings in textareas from conflicting with global keybindings (by making the latter use alt or meta as the accel-key).
Comment 82•22 years ago
|
||
Won't the Debug panel disappear from production releases? If this is a necessary & appropriate user feature (and I'm not arguing that it isn't), then the pref should exist in an ordinary preference panel. Maybe under Advanced. - In Unix, the names of the keys come (somehow) from keysyms, which are supposed to be "the letters or words that appear on the keys" independent of the physical keyboard or X server. The X server defines a limited (hardware-dependent) subset of keys which can be "Modifiers" (Ctrl, Alt, etc.) and only those can be pressed along with others to generate a single event. I'm guessing that the possible Modifier keysyms are a small fixed set, so their names could be hard-coded if necessary. But probably the name of the keysym can be obtained dynamically somehow. Does anyone know X internals sufficiently to say exactly how the available modifiers are defined and how to obtain their names?
Comment 83•22 years ago
|
||
What the X server does doesn't matter. What matters is what Mozilla's event handler does (e.g. nsGtkEventHandler.cpp for the gtk widget set). Currently, Mozilla knows about the modifiers Shift, Ctrl, Alt, and Meta; I don't think we have anywhere where we map those bits to user-readable names (look in the XUL menu code to see how the modifiers show up in menus, but I suspect the mapping is hardcoded there and I'm fairly sure it doesn't come from the platform event handler code, hence it doesn't come from the X server). Our event model isn't well defined (joki said a while ago that a new event spec was on the way, but I haven't heard any more about it so I don't know the timeframe for this). Re allowable values for accel: ui.key.accelKey is an int pref. If you set it to something that's not a modifier key (e.g. 'a') things won't work (my guess is that none of the accel bindings would ever fire, because the XBL code that looks for a match would never be satisfied) but in theory it should work for any modifier key (though AFAIK no one has ever tested setting accel to shift to see if the code works). Meta doesn't work on Unix in gtk (a bug: gtk on linux doesn't set a modifier bit when you press the windows key, though on some solaris boxes it does; note that the limitation is gtk and has nothing to do with the X server) and I believe it doesn't work on Windows either (also a bug, but not likely one that will ever be fixed).
Comment 84•22 years ago
|
||
What about using SHIFT-ENTER instead? This way we might steer clear of the accel problems while still employing an unused key binding.
Comment 85•22 years ago
|
||
Ok, since we're discussing what the pref should control and exactly how, sending over to jag, who's working on a consistent tabbrowser spec.
Assignee: bzbarsky → jaggernaut
Status: REOPENED → NEW
Comment 86•22 years ago
|
||
spun off a couple of bugs: bug 123414: clarify the wording for the "control+enter" tabbed browser pref. bug 123415: rfe asking whether we should implement "control+enter" to open in a new browser window.
Comment 87•22 years ago
|
||
*** Bug 123515 has been marked as a duplicate of this bug. ***
Comment 88•22 years ago
|
||
*** Bug 123615 has been marked as a duplicate of this bug. ***
Comment 89•22 years ago
|
||
*** Bug 123684 has been marked as a duplicate of this bug. ***
Comment 90•22 years ago
|
||
*** Bug 123797 has been marked as a duplicate of this bug. ***
Comment 91•22 years ago
|
||
*** Bug 124290 has been marked as a duplicate of this bug. ***
Comment 92•22 years ago
|
||
*** Bug 124804 has been marked as a duplicate of this bug. ***
Comment 93•22 years ago
|
||
*** Bug 124874 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 94•22 years ago
|
||
Now that 50255 is fixed, can we get an sr and check-in here?
Comment 95•22 years ago
|
||
sr and checkin for what exactly? See comment 64 and comment 71.
Reporter | ||
Comment 96•22 years ago
|
||
Oh... nifty... Looks like we need a 'checked-in' status for attachments. So assuming this will be working correctly tomarrow for Linux and Mac, maybe we should mark it FIXED and file a seperate bug to introduce an expando for pref pane text to reflect the current accel key value? Better yet, ditch the current pref, just have one main tab browsing pref, and advertise in the 0.9.9 release notes that now accel+enter opens in a new window, and if you have tab browsing enabled, opens in a new tab. Then we don't have to worry about the dynamic wording (which is likely to be a huge pain, and not at all cross platform).
Comment 97•22 years ago
|
||
*** Bug 122035 has been marked as a duplicate of this bug. ***
Comment 98•22 years ago
|
||
plain enter wfm using 2002021108 on win2K, anyone else still seeing the original reported problem? If so, reopen, if you're trying to morph this into ctrl+enter not working, then don't morph this, file a new bug.
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WORKSFORME
Comment 99•22 years ago
|
||
I still (or rather again) have the original nug in 2002022216 on Linux
Comment 100•22 years ago
|
||
This issue has been long gone. Any further problems should go into new bugs. Marking VERIFIED.
Status: RESOLVED → VERIFIED
Comment 101•22 years ago
|
||
*** Bug 136191 has been marked as a duplicate of this bug. ***
Comment 102•22 years ago
|
||
Comment on attachment 64870 [details] [diff] [review] Patch to fix this on Linux/Mac (pending bug 50255) (this had sr=hyatt and was checked in)
Attachment #64870 -
Attachment is obsolete: true
Attachment #64870 -
Flags: superreview+
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•