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

Status: RESOLVED WORKSFORME

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

Description

[calou]

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

Comment 1

[Sébastien Delahaye]

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

Comment 2

[Sébastien Delahaye]

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?

Comment 3

[John Morrison]

alt-enter with feenix 0.5 worksforme on win2k, but it does not work at all
on a winME box that I tried.

Comment 4

[Asa Dotzler [:asa]]

winme sucks :(

Comment 5

[paxunix]

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).

Comment 6

[paxunix]

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.

Comment 7

[paxunix]

Attachment: Fix at least for Win98, possibly all Windows platforms with problem

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.

Comment 8

[Vit Timchishin]

OS/2 version has the same problems

Comment 9

[paxunix]

Could I get a review on this patch?

Sorry I don't know the first thing about OS/2 stuff.

Comment 10

[Simon Paquet [:sipaq]]

Taking QA Contact

Comment 11

[paxunix]

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 12

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 13

[:deanis74]

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

Comment 14

[[e-mail]]

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...

Comment 15

[Gids Goldberg]

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=||

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

-> 0.9

Comment 17

[:deanis74]

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.

Comment 18

[Gids Goldberg]

Attachment: Alt and enter result on 98

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.

Comment 19

[Fredrik Tolf]

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.

Comment 20

[shadytrees]

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/

Comment 21

[Mike Connor [:mconnor]]

not critical for 0.9, maybe 1.0

Comment 22

[Brian Evans]

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.

Comment 23

[:deanis74]

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?

Comment 24

[Ben Goodger (use ben at mozilla dot org for email)]

+ing since there is a patch. 

Comment 25

[Asaf Romano (gone)]

Bug should be reassigned. Hyatt is no longer active in the project.

Comment 26

[mmortal03]

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.

Comment 27

[Thomas]

Target Milestone is overdue... Maybe we can change this to "Firefox 1.0" or
"after Firefox 1.0"?

Comment 28

[chris masters]

this has been fix on the trunk, but is still broken on the aviary.

Comment 29

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 30

[Ivan Ičin]

WFM with Firefox 1.5 on Win 98

Comment 31

[Christian Stadler]

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

Comment 32

[Jason Barnabe (np)]

WFM then.