561234 - QGraphicsWidget::keyPressEvent has an error that makes us invert case when typing

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Mike Kristoffersen (:MikeK)]

You need to hold down the shift key to get lower case letters, and release it to get upper case letters (with Fennec running on a Qt 4.6).

Comment 1

[Mike Kristoffersen (:MikeK)]

Attachment: Temporary workaround

The temporary fix makes us react on key release instead of key press, since the key release events have valid data (the key press event has invalid data).

Comment 2

[Doug Turner (:dougt)]

Comment on attachment 440915 [details] [diff] [review]
Temporary workaround

thanks!

Comment 3

[Doug Turner (:dougt)]

http://hg.mozilla.org/mozilla-central/rev/27d44d82781f

leaving open because it be nice to fix this for real.

Comment 4

[Mike Kristoffersen (:MikeK)]

This is also being tracked in the maemo bug system under bug no. 165779

Comment 5

[Jeremias Bosch (:jbos)]

I looked into this and it breaks the thing for us completely. Can you please revert to the old version and encapsulate the solution into a MOZ_PLATFORM_MAEMO=5 define?

Comment 6

[Doug Turner (:dougt)]

probably a good idea.

any idea why it is busted on maemo 5?

Comment 7

[Jeremias Bosch (:jbos)]

Mhm I don't think its a qt bug, I think it must be wrong within whatever handle the keyboard in the system and create the x-events send to the QApplication.

Comment 8

[Doug Turner (:dougt)]

Attachment: only enable work around on maemo 5

something like this...

Comment 9

[Jeremias Bosch (:jbos)]

Looks good that way. Thanks

Comment 10

[Jeremias Bosch (:jbos)]

We looked a bit more into this issue, also because of #562195. The real issue on Maemo5 looks like to be the QInputMethod provided by some Maemo5 QtStyle. This seems to break the KeyEvents. 

You could try to start Fennec with -style windows and see if this makes a difference for you. 

Just a thought, maybe the solution from #562195 makes a difference in this issue  too, or maybe it can help you to solve this issue.

Comment 11

[Steffen Imhof]

To expand a bit on that:

On Maemo5 the QHildonInputContext which seems to mess up the events is not added via a style or plugin, but instead compiled directly into the Qt version for Maemo5.

So it is not easy to circumvent without losing the virtual keyboard functionality. One option might be to filter events early, store needed information and use that when the messed up event reaches the MozQWidget. Or just wait for Qt ond Maemo5 to get fixed :-)

Bug #562195 seems (at least to me) completely unrelated, because here (#561234) the System/Qt events are already broken, while in #562195 the problem is the creation of the DOM keyevent inside our code, which behaves differently than the GTK version.

Comment 12

[Doug Turner (:dougt)]

I don't mind disabling the software keyboard completely and waiting for Qt and Maemo5 to get fixed.

steffen, can you put together a patch for such a thing?

Comment 13

[Doug Turner (:dougt)]

steffen, update?

Comment 14

[Oleg Romashin (:romaxa)]

I'm using now patch https://bugzilla.mozilla.org/attachment.cgi?id=441712, which is not in m-c now... is anything prevent us to push this patch to upstream?

Comment 15

[Oleg Romashin (:romaxa)]

I think ifdef maemo5 should be  just ok for now.

Comment 16

[Doug Turner (:dougt)]

http://hg.mozilla.org/mozilla-central/rev/c113774394ae