Closed Bug 185382 Opened 22 years ago Closed 18 years ago

alt+enter for opening URL in new tab doesn't work on WinME

Categories

(Firefox :: Toolbars and Customization, defect, P4)

All
Windows ME
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: fcalounec, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

I have Windows Millenium. When I try to use the keyboard shorcut "Alt+Enter"
after  having writen a new URL in the ToolBar, no new tab is opened.



Reproducible: Always

Steps to Reproduce:
1. Write a new URL in the ToolBars
2. used the keyboard shortcuts "Alt+Enter" to open a new tab for this new URL
3. No new tab opened

Actual Results:  
Nothing

Expected Results:  
Normally, Using the keyboard shortcut "Alt+Enter" after having writing a new URL
in the ToolBar ==>> open a new tab for this new URL 

I used the 
"C:\Program Files\Phoenix\Phoenix.exe" -ProfileManager
If you the folder "Profile", send me a email.
Thanks
Fred
This is WFM using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a)
Gecko/20021213 Phoenix/0.5

Reporter, could you please try with the latest nightly build a new profile (I'm
not sure that you used one, since I can't understand the last part of your report)?
You can find some help about that here: http://texturizer.net/phoenix/bugs.html
Severity: major → normal
OS: other → Windows ME
Summary: keyboard shortcut "Alt+Enter" for opening a new URL in new Tab in toolbars doesn't work → keyboard shortcut "Alt+Enter" for opening a new URL in new Tab in toolbars doesn't work
Via email:

-----
I tried with the latest nightly version and I built a new profile.
I can reproduce this "bug" . Everytime.

I wrote a new adress in the toolbars, used the keyboard shortcut "Alt+Enter" 
in order to open a new tab for this adress, but no new tab was opened ... 
nothing.


This keyboard shortcut "Alt+Enter" doesn't work, on widows ME maybe (??). I 
checked the
"tools" -> "Preferences" -> "Tabbed Browsing", everything was OK.

If you want, I can send you the new built profile I made with the latest 
nightly version of Phoenix.
-----

Please don't answer comments by email, but in Bugzilla.

Could another WinME user confirm this?
alt-enter with feenix 0.5 worksforme on win2k, but it does not work at all
on a winME box that I tried.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: keyboard shortcut "Alt+Enter" for opening a new URL in new Tab in toolbars doesn't work → keyboard shortcut "Alt+Enter" for opening a new URL in new Tab in toolbars doesn't work on WinME
winme sucks :(
Summary: keyboard shortcut "Alt+Enter" for opening a new URL in new Tab in toolbars doesn't work on WinME → alt+enter for opening URL in new tab doesn't work on WinME
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030411 Phoenix/0.5+

I'm confirming this on Win98 as well (both that it sucks and that it doesn't work).
Is this a toolbar-specific bug?  I fired up Venkman and set a breakpoint on
handleURLBarCommand() in browser.js.  It was never called when Alt+Enter was
typed in the URL bar, making me think the problem is deeper.  In fact, as near
as I can tell, Alt+Enter for anything in Mozilla or Firebird does nothing on my
Win98 box.

I looked a bit in
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp where
the key events are handled (though I'm unsure the problem is in there) but I
don't have a development env for Win98 so there isn't much I can do.

CC'ing saari for browser event-handling.
I've been running with this patch for a few days on a Win98 box. 
Unfortunately, I don't have any other Windows-not98 boxes to test it on,
although it seems unlikely it would be problematic.

Further testing welcomed.
OS/2 version has the same problems
Could I get a review on this patch?

Sorry I don't know the first thing about OS/2 stuff.
Attachment #124268 - Flags: review?(hyatt)
Taking QA Contact
QA Contact: asa → bugzilla
Status: NEW → ASSIGNED
Target Milestone: --- → Firebird0.8
Any chance for movement on this bug?  I realize it's pretty minor compared to
some of the others out there, but it makes a huge difference to us users stuck
on pre-Win2K Windows.

The typical usage goes like this:
1)  type some keyword bookmark or somesuch into the location bar
2)  hit Alt-Enter and watch nothing happen, when I expect the bookmarklet to be
eval'd in a new tab
3)  remember that you're on a Win9x box and then hit Ctrl-Enter like you did
back when you used Mozilla; curse like a sailor when your keyword-bookmark "URL"
is transformed into http://www.jseval alert("doh").com and you get "Invalid
Address Error" page
4)  close the tab
5)  in some other tab you don't want to get rid of, type in your keyword
bookmark again
6)  remember that, oh ****, you have to create a new tab first
7)  create a new tab, noticing that the URL was nicely blanked for you, blowing
away the keyword stuff you'd typed;  curse again when you go back to the tab
you'd typed the keyword into and notice that it was replaced with the URL of the
page loaded in the tab.
8)  Wish again that this bug was just plain fixed.

I apologize for that sounding snarky, but is there anyway this can get looked
at?  Some keywords that come to mind:  dataloss (though probably not critical),
polish, conversion, and perhaps even access (though that's probably stretching it).
Comment on attachment 124268 [details] [diff] [review]
Fix at least for Win98, possibly all Windows platforms with problem

Paxunix, it's targeted at 0.8, which means it'll be evaluated for this release.
I'm going to change your review request to Dean Tessman, who owns the bug that
the code block you're modifying was originally introduced to repair.
Attachment #124268 - Flags: review?(hyatt) → review?(dean_tessman)
Wouldn't we then need to eat the WM_CHAR message, assuming it comes through? 
Similar to this code in nsWindow.cpp.

             if ((mIsControlDown && virtualKeyCode == VK_RETURN)  ||
                 (mIsControlDown && virtualKeyCode == VK_BACK)) {
               result = PR_FALSE;
               break;
             }

That's not saying that this is the right approach.  I'm concerned what happens
on systems where Alt+Enter works properly.  Can you try the keyboard tester
(attachement 55849) attached to bug 50255 and report what you get for an
Alt+Enter keypress?  This is what I get on Win2K:

1) keydown charCode=0 keyCode=13 character=|| modifiers=Alt
2) keypress charCode=0 keyCode=13 character=|| modifiers=Alt
3) keyup charCode=0 keyCode=13 character=|| modifiers=Alt
Spy++ tells me:
WM_SYSKEYDOWN VK_MENU [Scan code 38]
WM_SYSKEYDOWN VK_RETURN [Scan code 1C]
WM_CHAR "\r"(13) [Scan code 1C] {only on NT}
WM_SYSKEYUP VK_RETURN [Scan code 1C]
WM_KEYUP VK_MENU [Scan code 38]
Isn't Windows wonderful? So, back to the subject, is there any way in which
peeking for the WM_CHAR message will help us? If there is a WM_CHAR message in
the message queue, chances is it's the one that TranslateMessage posted in
response to the WM_KEYDOWN message, but to be 100% sure you could probably check
for an equal lParam or something...
On Windows 98SE I get:
1) keydown charCode=18 keyChar=|| modifiers=Alt
2) keydown charCode=13 keyChar=| | modifiers=Alt
3) keyup charCode=13 keyChar=| | modifiers=Alt

4) keyup charCode=18 keyChar=||
-> 0.9
Target Milestone: Firebird0.8 → Firebird0.9
So no WM_CHAR message on Win98?  Lovely.  We could handle this in a couple of
ways.  One would be to fix this in nsWindow.cpp, which would mean this isn't a
FB-specific bug.  The quicker fix (aka "hack") would be to open the new tab on
Alt+Enter keyup instead of keypress.
I ran the test again on a win 98 and a win 98se box and got a different result.
I struggled to copy and paste the text so made a screenshot instead.
Just wanted to add to this that although Alt+Enter works for me (Mozilla/5.0
(X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8), it doesn't open
the URL in the background, although I've enabled the option and it works when
middle-clicking links.

Sorry if I should have opened a new bug for this.
You should post to the forums, not in Bugzilla, although I think (think, think) 
that Alt-Enter should automatically focus the new tab, and not respect the 
tab-in-the-background setting. Sorry for bugspam.
http://forums.mozillazine.org/
http://forums.mozillanews.org/
Flags: blocking0.9?
not critical for 0.9, maybe 1.0
Flags: blocking1.0?
Flags: blocking0.9?
Flags: blocking0.9-
With respect, as this is listed as a keyboard shortcut, I would consider it
critical that what is advertised as keyboard shortcuts does work in at least
1.0. Can't have users hitting bugs while following documentation IMO. But then
again, perhaps the documentation could just be changed instead.
Does anyone have both a Win98 and a Win2k/XP environment, where they could test
this patch on both to see how it affects those environments where it already works?
+ing since there is a patch. 
Flags: blocking1.0? → blocking1.0+
Bug should be reassigned. Hyatt is no longer active in the project.
Assignee: hyatt → dean_tessman
Status: ASSIGNED → NEW
Priority: -- → P4
Hardware: PC → All
I can confirm this bug on Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) 
Gecko/20040614 Firefox/0.9. (Windows ME)  BTW, Alt + Enter should also work in the
 search bar, but it does not work there either.  There is a separate bug report 
for this incorrect search bar behavior here at Bug 225215.  The bug report states
 that it is fixed, but it is still broken.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Target Milestone is overdue... Maybe we can change this to "Firefox 1.0" or
"after Firefox 1.0"?
this has been fix on the trunk, but is still broken on the aviary.
Assignee: dean_tessman → bugs
Assignee: bugs → nobody
QA Contact: bugzilla → toolbars
Target Milestone: Firefox0.9 → ---
Is this bug still present on recent builds? The relevant code has changed since
this bug was filed (bug 197474), I suspect this can be marked WFM.
Attachment #124268 - Attachment is obsolete: true
Attachment #124268 - Flags: review?(dean_tessman)
WFM with Firefox 1.5 on Win 98
Confirmed WFM on Win98 SE:
Mozilla/5.0 (Windows; U; Win98; de; rv:1.8) Gecko/20051111 Firefox/1.5

and on WinME:
Mozilla/5.0 (Windows; U; Win 9x 4.90; de; rv:1.8) Gecko/20051111 Firefox/1.5
WFM then.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: