[gtk2]pressing ENTER does nothing for password dialogs

RESOLVED FIXED

Status

()

--
major
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: ajschult784, Unassigned)

Tracking

({regression})

Trunk
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
With linux suite trunk 2005040101, when I get a dialog to enter a password for
the master password or a mail password, pressing ENTER has no effect.  I can
type in the dialog and hitting ESC cancels the dialog.  This only seems to
affect gtk2 (gtk1 is fine).  This regressed between build 2005033001 and
2005033107, which looks like Neil's checkin for bug 225563.
Anyone got VNC access to a build I can run tests on?
Flags: blocking1.8b2?
If you tell me what to test, I could do it (vnc into IBM isn't possible).
Well to start with at the XBL level you could add extra event listeners to
narrow down the range of when the event is prevented:
<handler event="keypress" keycode="VK_RETURN" phase="capturing"
action="dump(event.getPreventDefault() + ' capturing\n');"/>
<handler event="keypress" keycode="VK_RETURN"
action="dump(event.getPreventDefault() + ' bubbling\n');"/>
<handler event="keypress" keycode="VK_RETURN" phase="capturing" group="system"
action="dump(event.getPreventDefault() + ' capturing system\n');"/>
If all these dump false then there's something happening in editor, perhaps the
gnome keybinding support. If these all dump true then maybe it's aaronl's code.
(In reply to comment #3)
> Well to start with at the XBL level you could add extra event listeners to
> narrow down the range of when the event is prevented:
...
> If all these dump false then there's something happening in editor, perhaps the
> gnome keybinding support. If these all dump true then maybe it's aaronl's code.

The items Neil suggested to check all return false on my gtk2 system:

false capturing
false bubbling
false capturing system
I've tracked down the regression to the following window.

This one works fine:
Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8b2) Gecko/20050330 
(nightly build id 2005033006)
Present in:
Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8b2) Gecko/20050331
(nightly build id 2005033311)

URL for this window: (to which I've added 2 hours previous to the first build
id, as I have no idea if the 06 is start or finish time)
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-03-30+04%3A00&maxdate=2005-03-31+11%3A00&cvsroot=%2Fcvsroot

Theres a few things that may have caused it, but I haven't got enough experience
to look at them, hopefully someone else can pick this up now.
Could the GTK2 keybinding code be incorrectly binding the RETURN key?

Comment 7

14 years ago
When I get "Open Web Location" dialog to enter URL, pressing ENTER has no
effects, too.  I confirm this problem on 2005-04-11-06 gtk2+xft.tar.gz suite trunk.

Then, I got the source of 2005-04-14-05-trunk.  I replaced button.xml with a old
one.  I replaced dialog.xml and wizard.xml in the same way.  See bug 225563
about .xml files.  I made mozilla-gtk2+xft build(Fedora Core 3) which was based
on the replaced source of 2005-04-14-05-trunk.  Using this build, pressing ENTER
has effects on "Open Web Location" dialog.  I can use ENTER on a dialog to enter
master password.
weird thing is, this seems to work ok on firefox (bookmark properties is an example)
So if I remove group="system" from the VK_RETURN event handler, it starts working.
Please, this is a GTK2 specific bug, so don't look at XP files, thank you.
So
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsNativeKeyBindings.cpp#288
is hit.

I assume (gtk2 docs have no info) that gtk_bindings_activate checks if a gtk2
bindings exists for that control.  Which gtk2 does for return, arrow keys and
such it seems.
Created attachment 181830 [details] [diff] [review]
Possible patch

Anyone care to volunteer to test this?
Attachment #181830 - Flags: review?
You'd need r from bryner, I'll test tomorrow at work.
(Reporter)

Comment 14

14 years ago
Comment on attachment 181830 [details] [diff] [review]
Possible patch

the patch fixed the bug for me and didn't seem to break other things
(copy/paste,etc) included in the patch.
Comment on attachment 181830 [details] [diff] [review]
Possible patch

This makes it so that we only call preventDefault on a gdk binding that we
actually handle.
Attachment #181830 - Flags: superreview?(bryner)
Attachment #181830 - Flags: review?(bryner)
Attachment #181830 - Flags: review?
I tested and seems to work great.  

Comment 17

14 years ago
I tested patched suite build.  Password dialog has no problem.  The dialog of
"Open Web Location" works as well as password dialog.
*** Bug 291998 has been marked as a duplicate of this bug. ***

Comment 19

14 years ago
(In reply to comment #18)
> *** Bug 291998 has been marked as a duplicate of this bug. ***


The above patch works for me too.  I had the duplicate bug 291998.

Comment on attachment 181830 [details] [diff] [review]
Possible patch

I think this may be a bug in gtk, but this seems like a good idea in any case.
Attachment #181830 - Flags: superreview?(bryner)
Attachment #181830 - Flags: superreview+
Attachment #181830 - Flags: review?(bryner)
Attachment #181830 - Flags: review+
Comment on attachment 181830 [details] [diff] [review]
Possible patch

Would be nice to be able to work around this gtk2 bug.
Attachment #181830 - Flags: approval1.8b2?
Comment on attachment 181830 [details] [diff] [review]
Possible patch

a=asa
Attachment #181830 - Flags: approval1.8b2? → approval1.8b2+
Fix checked in (four days ago).
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

14 years ago
Flags: blocking1.8b2?
You need to log in before you can comment on or make changes to this bug.