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

RESOLVED WORKSFORME

Status

()

Firefox
Toolbars and Customization
P4
normal
RESOLVED WORKSFORME
16 years ago
13 years ago

People

(Reporter: calou, Unassigned)

Tracking

unspecified
All
Windows ME
Points:
---
Bug Flags:
blocking0.9 -
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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

16 years ago
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

Comment 2

16 years ago
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

16 years ago
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

Updated

16 years ago
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

Comment 4

16 years ago
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

Comment 5

15 years ago
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

15 years ago
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

15 years ago
Created attachment 124268 [details] [diff] [review]
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

15 years ago
OS/2 version has the same problems

Comment 9

15 years ago
Could I get a review on this patch?

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

Updated

15 years ago
Attachment #124268 - Flags: review?(hyatt)
Taking QA Contact
QA Contact: asa → bugzilla

Updated

15 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Firebird0.8

Comment 11

15 years ago
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)

Comment 13

15 years ago
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

15 years ago
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

15 years ago
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

Comment 17

15 years ago
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

15 years ago
Created attachment 137568 [details]
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

15 years ago
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

14 years ago
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/

Updated

14 years ago
Flags: blocking0.9?
not critical for 0.9, maybe 1.0
Flags: blocking1.0?
Flags: blocking0.9?
Flags: blocking0.9-

Comment 22

14 years ago
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

14 years ago
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

Comment 26

14 years ago
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.

Updated

14 years ago
Flags: blocking-aviary1.0+ → blocking-aviary1.0-

Comment 27

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

Comment 28

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

Updated

14 years ago
Assignee: dean_tessman → bugs

Updated

13 years ago
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)

Comment 30

13 years ago
WFM with Firefox 1.5 on Win 98

Comment 31

13 years ago
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

13 years ago
WFM then.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.