Closed Bug 322764 Opened 19 years ago Closed 19 years ago

Win98SE and WinME / keyboard problem: Can't start trunk FFv1.6a1 or SMv1.5a tinderbox zip or exe builds as of 08 Jan with old or new profile

Categories

(Core :: Widget: Win32, defect)

Product:
Core
Component:
Widget: Win32
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: u52928, Unassigned)

References

Details

Attachments

(1 file)

Possible fix for Win9x
8.31 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060107 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060107 Firefox/1.6a1

I've been using trunk tinderbox hourly builds on a daily basis for over a year. Sometimes I download and set up more than one build per day.

Today - as always - I unzipped into a new folder, clicked my desktop link, and my computer froze. I repeated the entire process, but with a new profile. It made no difference.

I was unable to start the program.

Reproducible: Always

Steps to Reproduce:
1. Download trunk tinderbox build (I used six different hourlies during the course of today)
2. Unzip into new folder
3. Go to C:\Windows\Application Data -> erase "Mozilla" folder
4. Click link to Firefox.exe or click directly on file in install folder

Actual Results:  
Computer freezes. Have to kill "Firefox" process in "Close Program" dialog. There's no error message.

Expected Results:  
Firefox should open.

I've checked with the forum; only Peter(6) replied, saying he had no trouble on Windows XP. Problem seems to be with Windows 98SE. I tried it on my wife's machine that's also running 98SE, and the result was identical to that on mine: couldn't start FF. 

Yesterday's build - Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060107 Firefox/1.6a1 ID:2006010708 - works fine. So does today's branch tinderbox.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060108 Firefox/1.6a1 ID:2006010806

WFM. Did you get an alert from your firewall that asked you for permission to connect to the internet?
Does it work when you start Firefox from another location?
This is WFM with a Win95 VM (I don't have a Win98 VM handy) and WinXP with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060108 Firefox/1.6a1
Summary: Can't start trunk (1.6a1) tinderbox zip builds as of 08 Jan with old or new profile → Win98SE problem: Can't start trunk (1.6a1) tinderbox zip builds as of 08 Jan with old or new profile
Confirmed on my W98SE computer:
seamonkey/nightly/2006-01-07-10-trunk works
seamonkey/nightly/2006-01-08-10-trunk hangs

Actual result:
startup banner does not even show up,
xpti.dat file is created, compreg.dat file is NOT created,
mouse/... is locked up, until I press C-A-D to get to the Windows process dialog.
Severity: critical → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Win98SE problem: Can't start trunk (1.6a1) tinderbox zip builds as of 08 Jan with old or new profile → Win98SE problem: Can't start trunk FFv1.6a1 or SMv1.5a tinderbox zip builds as of 08 Jan with old or new profile
Version: unspecified → Trunk
So, it looks as if only one person checked in between those times, although I don't know the patches so I can't tell why they might be a problem.
couldn't start on my Win98 computer. I've got a permanent shortkey loading seamonkey.exe -Profilemanager, also Zonealarm comes up and asks me for permission. This didn't happen with todays nightly, it went to 85% CPU, rest consumed by procexp and other apps.
I'm suspecting bug 287179. Dainis, do you have a chance to check this?
Blocks: 287179
Flags: blocking1.9a1?
I had the same very hang on Windows ME with a fresh CVS Seamonkey trunk build shortly after bug 287179 patch.. I cannot confirm this as the result. My previous CVS build was on 20050105 (Thursday). Early tester of bug bug 287179 worked for me (I was an active tester for that bug). 

Could you refresh my memory on how to revert the CVS treee to a moment before the patch (let's say 2006-01-07 10:40)? This info is missing in the present version of http://developer.mozilla.org/en/docs/Mozilla_Source_Code_Via_CVS

BTW, Changing the summary to add WinME.
Summary: Win98SE problem: Can't start trunk FFv1.6a1 or SMv1.5a tinderbox zip builds as of 08 Jan with old or new profile → Win98SE and WinME problem: Can't start trunk FFv1.6a1 or SMv1.5a tinderbox zip builds as of 08 Jan with old or new profile
Unfortunately I do not have Win98 available where I can debug problem. I will try at evening to check the Win9x code path on WinXP.

What are your Windows regional settings and active keyboard layout? What processor?

Probably I made mistake with explicit type casts when fixing MinGW bustage. Did your build include the checkin from 2006-01-08 01:40? Can you try to undo it?
Jacek, which was the last patch that worked for you?
OK, I found the info. I added:
set MOZ_CO_DATE=01/07/2006 10:40:00
but it used my timezone, not mozilla.org's.
OK, I'll correct by 9 hours (01/07/2006 19:40:00) and then rebuild mozilla with the pre- bug 287179 tree in the (European) afternoon (no time for this now).


Replying to comment #8:

I had this hang with and without your last MinGW patch. I built Seamonkey yesterday twice and both times I hasd the same result: a start hang before the splashscreen.

The last patch I used was the one before you started to include the superreviewers's comments: patch 206803 (Christmas day 20051225).
(In reply to comment #8)

I forgot this part:
> What are your Windows regional settings and active keyboard layout? What
> processor?

Original US WindowsME, purchasd in California. Regional settings are: Language=English, 
Country=United Kingdom - not Poland, to avoid having comma as the decimal sign which kills some of my software compatibility. 
Keyboard=Polish, more exactly "Polish (Programmers)" - this is the one using GreyAlt.

Processor: Pentium III, 866MHz.
Related to comments 8 and 10
Changing the summary to add the .exe build

Dainis:

The problem is both in the zip and .exe builds and is definitely related to the keyboard settings.

Having read Jacek's comment, I decided to test the keyboard. Although I have a US English version of Windows 98SE, I did not have the US English keyboard installed, only German Standard. 

My regional settings are English UK.

I installed the US English keyboard, but kept German Standard as my default keyboard, and FF still didn't work.

I then switched the default keyboard to US English, rebooted, and FF started perfectly, even using my old profile. 

I guess I have to apologize, but I'm an English teacher and have very little idea of how computers actually work. After this testing, though, there's little question in my mind that the problem is somehow related to the link between the keyboard setting and the "fixing MinGW bustage".
Summary: Win98SE and WinME problem: Can't start trunk FFv1.6a1 or SMv1.5a tinderbox zip builds as of 08 Jan with old or new profile → Win98SE and WinME problem: Can't start trunk FFv1.6a1 or SMv1.5a tinderbox zip or exe builds as of 08 Jan with old or new profile
(In reply to comment #8)
> What are your Windows regional settings and active keyboard layout? What
> processor?

French, French, AMD K6.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060108 Firefox/1.6a1 ID:2006010904

Addition to my comment 11:

With Win 98SE, you can change the keyboard settings using LeftAlt + Shift.

When FF was already running, and I changed the keyboard settings from English US to German Standard, FF immediately froze!    
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060108 Firefox/1.6a1 ID:2006010823

It's not advisable to try shift+left alt with a trunk build open if you had not planned to shut down your computer.
It is definitely bug 287179. 

works in 20060107 1040pst build
fail  in 20060108 0100pst build

which means it's neither bug 322185 nor bug 318894 .
The only thing that actually can hang is KeyboardLayout::EnsureDeadKeyActive(). On WinXP when I enforce the mIsNT=FALSE and take Win9x code paths everything works fine.
Can anybody with debugger verify that we are hanging in EnsureDeadKeyActive() and look at stack which function called it with what parameters?

Jacek, According to comment #11 by Joe Greenman everything works if system language matches keyboard language then there is no hang. Are you sure that when you tested patch 206803 you had not similar setup. Were you able to switch languages without hang?

Seems that hang is observed only by people (Joe, Jacek) that has keyboard layout with dead-key combinations (German, Polish). English UK does not dead-keys and it works fine.
I'm rebuilding now mozilla 20051225 with patch 206803 to test the comment #16 hypotesis. 

Actually, I am positive that I used Polish keyboard because I tested the patch writing letters that are not possible to produce with any other keyboard. However, I'm not 100% sure that I had Language=English setting at the time (which theoretically could also influence the result, couldn't it?).
Jacek,
If 206803 was really working then in trunk version please replace:
  ::MultiByteToWideChar (mCodePage, 0, (LPCSTR)&ascii, rv, (WCHAR*)&deadChar, 1);
with 
  ::MultiByteToWideChar (mCodePage, 0, (LPCSTR)&ascii, 1, (WCHAR*)&deadChar, 1);

rv->1. That is the only obvious difference between 2068039 (works) and 206856 (fails). Probably there is some difference between WinXP and Win9x how ::MultiByteToWideChar works when target buffer is smaller than source buffer.


I hope no one will consider this "spam" -> I sincerely thank you all for working on this. I see that it's a pretty "special" problem that only affects a few people. 

Again, thanks very much. 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060109 Firefox/1.6a1 ID:2006010905

When I hit shift+left alt and trunk build window is open, the mouse wheel stops scrolling the page and the action changes into back or forward and I can't type anymore in an inputfield. Or when I click an email link in my Gmail inbox I get a message that a need to disable my popup blocker. If I close Firefox I can't do anything anymore than restarting the computer for when I double-click Firefox to start it again it refuses to start and instead I get a message that "I'm going to open 32 items at the same time" or nonsense like that or I see the Properties window. When I click on my desktop all icons are selected. And shift+ right alt does help anymore after closing Firefox.
I can't do anything anymore but rebooting.
The behaviour differs everytime but after a reboot all works normally again.
I have bad news. My new mozilla 20051225 build patched with patch 206803 now does not work for me. In fact it hands with any regional settings and keyboard I try (including a totally English one). 

The only explanation is that I did not clobber the tree before "setting back the clock" (that is pulling a historical CVS tree). I'm not sure if "make -f client.mk build" works 100% fine when you downgrade the files. So I'm clobbering the tree now. But I doubt I will have time today to rebuild it. Expect some results tomorrow afternoon.

BTW, there is another way of avoiding the reboot after hang. You need to simply press Ctr-Alt-Del and keyboard scroll (if the mouse hangs) to the Seamonkey (or Firefox) process that is hanging and then use the tab key to reach End Task button and press Enter.
(In reply to comment #21)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060109
> Firefox/1.6a1 ID:2006010905
> 
> When I hit shift+left alt and trunk build window is open, the mouse wheel stops
> scrolling the page and the action changes into back or forward and I can't type
> anymore in an inputfield.

    (In reply to comment #21)
    > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060109
    > Firefox/1.6a1 ID:2006010905
    > 
    > When I hit shift+left alt and trunk build window is open, the mouse wheel stops
    > scrolling the page and the action changes into back or forward and I can't type
    > anymore in an inputfield....

    I'm not quite sure what Ria is trying to point out here, since this bug - as far as I know - is only related to Win98SE / ME. 

    I mentioned that my comment #13 - about shift+left alt - pertained to Win 98SE. 

    Maybe I should have added that this action is actually a link that runs Windows\system\internat.exe  This is a little program that allows changing the keyboard language by means of an icon in the task bar (next to the Windows clock - in the lower right corner of the screen on my machine). 
Jacek,
Check comment #19. You can easily apply it over trunk version.
And you can build only the widget, not entire tree. (cd objdir/widget; make)
Dainis,

I did notice your comment #19 request but:

a) patch 206803 could not be applied to the present tree (unlike the later ones)
b) because now Seamonkey with patch 206803 also hangs, what would be the point of applying the comment #19 change?
c) my tree is now clobbered anyway so the suggestion is pointless at least until tomorrow afternoon.
Joel - what I meant to point out is that this behaviour only exists in the latest trunk versions, that I can't reproduce it in branch builds and that no keystroke should cause Firefox to hang. 
(In reply to comment #26)
> Joe - what I meant to point out ...

OK, thanks. Sorry. I certainly didn't mean it as any type of criticism; I just didn't understand. 
Dainis, 

I made the change suggested in comment #19. Now with and without this change, I have the same hang. 
Do you want to say that patch 206803 never worked for you? I will mail you small test program in a moment.
No, I'm sure that it did work when build on 20051226. However, I cannot explain why it did then and why I cannot reproduce the same result now.

I'm starting to suspect the patch may have not correctly applied back in December.  The patch function output looked good, except a warning about an offset by 12 lines (as far as I remember) but who knows...
Platform SDK does not claim that ::ToAsciiEx returns -1 for dead-keys (as in case for ::ToUnicode). Documentation says that negative number is returned. That difference possibly can explain hang.

Please test this and report back. Fingers crossed.
Changed summary from "Win98SE and WinME problem..." to "Win98SE and WinME / keyboard problem..."

(In reply to comment #16)
<snip> 
> Jacek, According to comment #11 by Joe Greenman everything works if system
> language matches keyboard language then there is no hang. 

Just to keep things clear for my simple mind, let's distinguish among "system language" (which language version of Windows one is using), regional settings, and keyboard language.

If you look at comment #12 from Serge, he's using French regional settings and a French keyboard. I also assume he's using a French version of Windows. That means all three components are French, and nonetheless, he apparently also has the problem.

What I meant was that my German keyboard was causing the problem in combination with my US English Windows. 

Just now I tested things again by changing my regional settings from UK English to German but leaving my keyboard language set to German. That is, my Regional Setting is German, my keyboard is German, but my (Windows operating) system language is US English. Result: the latest trunk build (10 Jan) "hung"; I had to use C-A-D.

Just to repeat, the only way I've been able to get the trunk to work is to have US English set as my default keyboard. 

One thing I forgot to mention though: when I had US English set as my default language and was able to use the trunk, I could use the German keyboard in other apps (Word, etc.) As soon as I started the FF trunk, though, the keyboard language "automatically" changed to English!!!  

Just for the heck of it, I also tested the trunk using an Arabic keyboard layout (I've studied Arabic for many years). The trunk hung.

Anyway, this all indicates - as far as I can see - the issue is not that the keyboard language and the operating sytem language have to be the same, but rather that any non-English keyboard (languages with "dead keys"???) will cause the problem regardless of which Windows language version you're using. . 

It would also be interesting to hear from someone who's using a German keyboard and a German version of Windows still has the problem.  Based on Serge's experience, I'd guess the answer would be yes. 

One thing that's confusing me a bit is this comment that I got in response to my posting on the forum:
------------------------------------
JanT / Joined: 18 Mar 2004 / Eindhoven, NL / Posted: Jan Sun 8th 2006 3:34pm  
   
Hello JoeG,
At this moment I'm using Firefox 1.6a1 nightly 2006010806 on Win 98 SE. Win 98 SE in Dutch and FF in English and Dutch. 

Everything seems to work properly.
Mozilla/5.0 (Windows; U; Win98; nl; rv:1.9a1) Gecko/20060108 Firefox/1.6a1
-----------------------------------------------

I'm going to write to him and ask what his default language is.

Last but not least, just for the record, since comment #8 asked which processor people experiencing problems are using, I have an Althlon Thunderbird 1.2 gh.
Summary: Win98SE and WinME problem: Can't start trunk FFv1.6a1 or SMv1.5a tinderbox zip or exe builds as of 08 Jan with old or new profile → Win98SE and WinME / keyboard problem: Can't start trunk FFv1.6a1 or SMv1.5a tinderbox zip or exe builds as of 08 Jan with old or new profile
(In reply to comment #32)
> If you look at comment #12 from Serge, he's using French regional settings and
> a French keyboard. I also assume he's using a French version of Windows. That
> means all three components are French, and nonetheless, he apparently also has
> the problem.

I confirm: 3 French and 1 issue ;->
No, patch 208117 does not help.

Dainis, could you send me a simple program (source code) including the functions you want me to debug which I could run it with MSVC 6?
I'm using a german Win98 (Standard Edition, not Win98SE) and Seamonkey nightlies in default language (en-us). I rarely use language packs, mostly shortly for testing a release. Celeron 333, 128 MB.
(In reply to comment #35)
> I'm using a german Win98 (Standard Edition, not Win98SE) and Seamonkey
> nightlies in default language (en-us). I rarely use language packs, mostly
> shortly for testing a release. Celeron 333, 128 MB.

What's your keyboard language setting? 

I'm using a German "Tastatur" and the German (Standard) keyboard setting. That crashes the FF trunk. 

However, when I installed the US English keyboard layout - even if the German keyboard language setting was my default - I could run the trunk.
---------
In regard to the part in my comment #32 where I referred to JanT - who's using Dutch Windows but was able to get the trunk to work, he just sent me a private message that said:

My keyboard is a standard US-keyboard. Most of the time the settings is "United States 101", the normal setting. Sometimes I use the setting "US (International)" when using characters with accents (umlaut, etc).

The Window 98 SE is the normal Dutch version, ... The computer is a Celeron 300 MHz with 256Mb RAM  

Again, he's using a US English keyboard, and the trunk works.
I will repeat my comment #17 - The problem is seen only with keyboard layouts that uses dead-key combinations. French, German, Polish, Czech, Latvian, United Kingdom Extended, United States International, Arab(?) all use dead-keys. United States (default), United Kingdom (default), Russian keyboards do not have dead-keys.

The problem is not in any way related to System language, regional settings, Firefox language or processor speed.
Component: Startup and Profile System → Widget: Win32
Product: Firefox → Core
(In reply to comment #37)
> I will repeat my comment #17 - The problem is seen only with keyboard layouts
> that uses dead-key combinations. French, German, Polish, Czech, Latvian, United
> Kingdom Extended, United States International, Arab(?) all use dead-keys.
> United States (default), United Kingdom (default), Russian keyboards do not
> have dead-keys.
> 
> The problem is not in any way related to System language, regional settings,
> Firefox language or processor speed.

To corroborate this, I just got another  message from JanT in Holland:
-------------------------
I did a test: Default keyboardsetting is "United States 101". Start Firefox 1.6a1, all fine.
Switch to "US (International)", Firefox freezes, need Ctr-Alt-Del to kill FF en continue with Windows.
--------------------------
Now that the dead- key cause has been identified, wouldn't it be possible either to fix it or remove the "fix" that broke it? It seems pretty clear that the problem started on 07-08 Jan. 
When you say hang you mean 100% CPU usage or Firefox is not responding to mouse/keyboard input, but still continues to animate GIF images or Flash? System will always handle Ctrl+Alt+Del combination.
I wonder if that could be problem of ::BlockInput API function. Unlikely, because then it would have same effect on EN-US keyboard layout, too.
(In reply to comment #39)
> When you say hang you mean 100% CPU usage or Firefox is not responding to
> mouse/keyboard input, but still continues to animate GIF images or Flash?
> System will always handle Ctrl+Alt+Del combination.
> I wonder if that could be problem of ::BlockInput API function. Unlikely,
> because then it would have same effect on EN-US keyboard layout, too.
> 
Excuse me Dainis, which comment are you referring to?
Never mind, I've already received information from Jacek that we take almost all CPU time and thus hanging. I am going to install virtual machine and debug problem.

Found interesting info about behaviour difference of ToAsciiEx under WinXP and Win98.
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/win-dead-keys.html

That could explain why I can't recreate it on WinXP.
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060107 SeaMonkey/1.5a] (nightly) (W98SE)

(Confirming that my French/French works with US-101 keyboard setting, but hangs with French k.s..)
I've tested the attached patch with Win98SE with Czech, French and German keyboards and it did not froze neither under VirtualPC neither with real computer. I've used debug printouts to verify that dead-key characters are detected.
Now I have to verify if original patch for bug 287179 is working or not.

(In reply to comment #43)
> I've tested the attached patch with Win98SE with Czech, French and German
> keyboards and it did not freeze either under VirtualPC or with real
> computer. I've used debug printouts to verify that dead-key characters are
> detected.
> Now I have to verify if original patch for bug 287179 is working or not.
> 
Thank you for your ongoing help with this. It will be great if you can fix it.
(In reply to comment #43)
> I've tested the attached patch [...]

Which patch? May I test it as well?
Just verified that current trunk version that is hanging for some users, is working fine for me on Win98SE v4.10.2222A both on VirtualPC and real machine.

1. Can those persons that experienced hang report exact Windows version? Right mouse click on "My computer", select "Properties" and then "General" tab.
2. Please also report whether you use English or some localized version of Windows 9x? 
3. Are you all using standard Microsoft supplied keyboard layouts or is it some third party software solution?
4. Is there any other person except me that had no problems on Win9x with French, German, Polish, Czech or whatever keyboard layout that has dead-key combinations?

You may want to send this info directly to my email address to avoid the needless spam in thus bug. I will later post some overview information about those version that work and those that don't.

We are going to back out fix for bug 287179, so your troubles will soon be over :)
Thanks very much for backing out. 287179. Now the trunk works again.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060114 SeaMonkey/1.5a] (nightly) (W98SE)

V.Fixed.
Status: RESOLVED → VERIFIED
Flags: blocking1.9a1?
Target Milestone: --- → mozilla1.9alpha
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: