480768 - Menus don't turn gray when a dialog is opened, and turn gray when it's closed (even though the main window is focused)

Status: VERIFIED FIXED

(Core :: DOM: Events, defect)

Description

[Nochum Sossonko [:Natch]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090228 Minefield/3.2a1pre

Summary says it all, 3.1 branch doesn't suffer from this yet. I'll look for a regression range.

STR:

1. open the clear recent history dialog.
2. observe main window menu text is still black.
3. close the dialog.
4. observe the main window menu text has now turned gray.

Comment 1

[Nochum Sossonko [:Natch]]

works: 2009-02-26
broken: 2009-02-27
pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a979ac23e17e&tochange=cc8d4e656113

No idea which one specifically did this...

Comment 2

[Nochum Sossonko [:Natch]]

Alas I was wrong, this does happen on 3.1 latest... I'll try to get a range for that as well.

Comment 3

[Nochum Sossonko [:Natch]]

in 3.1:

works: 2009-02-27
broken: 2009-02-28
pushlog: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=9865a6c60c5b&tochange=53bc33d54b14

I suspect one of Olli's checkins, though can't be sure...

Comment 4

[Nochum Sossonko [:Natch]]

hg bisect:

The first bad revision is:
changeset:   25570:7184f7d69ff0
user:        Olli Pettay <[e-mail]>
date:        Thu Feb 26 14:00:30 2009 -0800
summary:     Bug 333198 - 'Suppress Input events for web content during synchron
ous XMLHttpRequest loads'. r=bz, sr=jst, a=blocking1.9.1+

Comment 5

[Nochum Sossonko [:Natch]]

Updating summary to reflect what is happening, after this happens you can no longer type in the address bar, etc.

Comment 6

[Nochum Sossonko [:Natch]]

IMHO this should be a beta 3 blocker as the focus and event delivery is pretty much clobbered.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This does only affect textboxes for the current xul window, right? Other elements seem to work. It's a Windows only bug and not reproducible on Linux or OS X.

Beltzner, what do you think?

Comment 8

[Nochum Sossonko [:Natch]]

Well not entirely, it screws up focus in general, hence the str. See also bug 480767.

Comment 11

[Willie Reid]

This bug is marked as Core but I'm not seeing it (or any duped bug behaviours) in Seamonkey. Using Windows XP.


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090228 SeaMonkey/2.0b1pre - Build ID: 20090228001403

Comment 12

[Jim Jeffery not reading bug-mail 1/2/11]

Is this bug also causing the navigation keys to stop working ? 
Navigation keys, arrow keys, pg/up/dwn/home/end all quit working after entering into and exiting Private Browsing. 

No errors in console2.  
Seeing this using Vista HP SP1 trunk builds:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090228 Minefield/3.2a1pre Firefox/3.0.4 ID:20090228133751

Latest hourly with changeset: 
http://hg.mozilla.org/mozilla-central/rev/40a26979f070

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

This was done on purpose, but apparently there

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #13)
> This was done on purpose, but apparently there
Er, I mean "Events on parent window are suppressed when modal dialog is opened. "
was done on purpose. But of course not the menu handling change.

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

I think limiting suppression to content docshells might work well enough.

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

I'll try to find some solution ASAP, or backout all the timeout suspension / user event suppression changes.

Comment 17

[Nochum Sossonko [:Natch]]

Smaug, it isn't just a "menu handling" problem, see the duplicate bugs, the events are suppressed *after* the dialog has been closed, that is the problem. If I open a modal dialog, I can't type anything into any text input until I unfocus the window, then refocus it.

There also seems to be a focus problem, the focus isn't taken from the parent window until the dialog is closed.

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

Bug 480767 isn't a dup of this one.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I can see this problem too when switching and leaving the Private Browsing mode. I've disabled the dialog, so no modal dialog is needed to get into this state.

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

TryServer builds with a patch https://build.mozilla.org/tryserver-builds/2009-03-01_08:[e-mail]-suppress_only_when_needed/

But I'm currently testing also another approach.

Comment 21

[Nochum Sossonko [:Natch]]

That tryserver fixes all the regressions for me.

Comment 24

[Jim Jeffery not reading bug-mail 1/2/11]

This is seemingly WFM - fixed by 333198 ? 

Using Vista HP SP1

today's nightly:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090304 Minefield/3.2a1pre Firefox/3.0.4 ID:20090304034918

Comment 25

[Olli Pettay [:smaug][[e-mail]]]

Bug 333198 caused this, then it was backed out and pushed back
with the fix for Bug 480767.

Comment 26

[Johnny Stenback (:jst)]

Smaug and others, this is fixed now, right?

Comment 27

[Nochum Sossonko [:Natch]]

This is fixed for me and Smaug mentioned in bug 480767 comment 7 that it would.

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed on trunk and 1.9.1:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090304 Shiretoko/3.1b3pre ID:20090304033811

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090304 Minefield/3.2a1pre ID:20090304034918