Bug 40062 – [Qt] On Maemo6 platform auto upper case and predictive text input method hints are not disabled for password field

• Component: WebKit Qt
• Status: RESOLVED FIXED

[Raine Makelainen]

In EditorClientQt::setInputMethodState(bool active) on Maemo6 platform auto upper case and predictive text input input method hints are not disabled for password field.

This affect to Virtual Keyboard behaviour.

[Raine Makelainen]

Created attachment 57657 [details]
Fix proposal for disabling auto upper case and predictive text for password field

[Kenneth Rohde Christiansen]

Comment on attachment 57657 [details]
Fix proposal for disabling auto upper case and predictive text for password field

WebKit/qt/ChangeLog:11
 +          No new tests.
If there are no new tests you should explain why, or at least leave out this line.

R=me, but please fix this and reupload.

[Raine Makelainen]

Created attachment 57666 [details]
Fix proposal 2 for disabling auto upper case and predictive text for password field

[WebKit Commit Bot]

Comment on attachment 57666 [details]
Fix proposal 2 for disabling auto upper case and predictive text for password field

Clearing flags on attachment: 57666

Committed r60589: <http://trac.webkit.org/changeset/60589>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Simon Hausmann]

Hnmmn, where is Q_WS_MAEMO_6 defined? I don't see that in the Qt 4.7 builds that are in the queue for Maemo 5.

[Kenneth Rohde Christiansen]

Thiago, do you know about this?

[Thiago Macieira]

It's not defined in the official Qt sources. I believe productisation adds it, so it's internal API, not available for webkit.

[Raine Makelainen]

(In reply to comment #6)
> Hnmmn, where is Q_WS_MAEMO_6 defined? I don't see that in the Qt 4.7 builds that are in the queue for Maemo 5.

Rodrigo, added this for now to:
http://gitorious.org/+qtwebkit-packagers/webkit/qtwebkit-maemo6/blobs/master/debian/rules.

[Simon Hausmann]

(In reply to comment #9)
> (In reply to comment #6)
> > Hnmmn, where is Q_WS_MAEMO_6 defined? I don't see that in the Qt 4.7 builds that are in the queue for Maemo 5.
> 
> Rodrigo, added this for now to:
> http://gitorious.org/+qtwebkit-packagers/webkit/qtwebkit-maemo6/blobs/master/debian/rules.

That's nice, but it's not practical for development. The ability to detect Maemo 6 must come from Qt.

Thiago, do you know of any plans to add this to Qt?

[Thiago Macieira]

Last I checked, there were plans to NEVER add it to Qt.

Maemo 6 is X11, there are no differences. 

If you need to find out more information, you need to add an API for it. I doubt that you're looking for Maemo 6 anyway, but instead to some specific aspect of it that could exist in other X11-based devices.

That's why I have strongly opposed ever adding QT_WS_MAEMO_6.

[Simon Hausmann]

(In reply to comment #11)
> Last I checked, there were plans to NEVER add it to Qt.
> 
> Maemo 6 is X11, there are no differences. 
> 
> If you need to find out more information, you need to add an API for it. I doubt that you're looking for Maemo 6 anyway, but instead to some specific aspect of it that could exist in other X11-based devices.
> 
> That's why I have strongly opposed ever adding QT_WS_MAEMO_6.

Alternatively what would suffice for us would be a way to detect that we're building for a mobile platform, _or_ !desktop for something slightly wider.

It would be nice if that came from Qt. Otherwise we have to ask people to build webkit with

    qmake CONFIG+=mobile

if they want to build for a mobile platform, and we introduce our own defines.

But then we'd have the same problem within Qt: When WebKit is compiled within Qt for Symbian, Maemo5 or Maemo6 we would want to set that configuration...

[Thiago Macieira]

I still disagree. What is a netbook? It's halfway between a desktop and a handheld.

If you are looking for the form-factor, you should be able to get that from a Qt API. I doubt that you are, though.

You are looking for some information on the input mechanisms that exist for the current device.

[Kenneth Rohde Christiansen]

(In reply to comment #13)
> I still disagree. What is a netbook? It's halfway between a desktop and a handheld.
> 
> If you are looking for the form-factor, you should be able to get that from a Qt API. I doubt that you are, though.
> 
> You are looking for some information on the input mechanisms that exist for the current device.

If Qt could define these input method flags and put them all in Qt 4.7, we would have no problem, as they could be ignored by platforms not knowing about them.

I guess the problems is that these are not defined for vanilla Qt, but only for the one distributed with Maemo5 and Symbian.

[Simon Hausmann]

(In reply to comment #14)
> (In reply to comment #13)
> > I still disagree. What is a netbook? It's halfway between a desktop and a handheld.
> > 
> > If you are looking for the form-factor, you should be able to get that from a Qt API. I doubt that you are, though.
> > 
> > You are looking for some information on the input mechanisms that exist for the current device.
> 
> If Qt could define these input method flags and put them all in Qt 4.7, we would have no problem, as they could be ignored by platforms not knowing about them.
> 
> I guess the problems is that these are not defined for vanilla Qt, but only for the one distributed with Maemo5 and Symbian.

Actually these flags are available on all platforms. We could remove the #ifdefs and it would compile.

But the question really is: Why is predictive text input and auto-uppercasing disabled for mobile devices?

Right now it's done for _any_ inputs, and if it should be done only for password fields, then it should be the input method that decides to do that, because it has all the hints set.

I'd like to remove this block of code altogether.

[Eric Seidel (no email)]

Comment on attachment 57657 [details]
Fix proposal for disabling auto upper case and predictive text for password field

Cleared Kenneth Rohde Christiansen's review+ from obsolete attachment 57657 [details] so that this bug does not appear in http://webkit.org/pending-commit.

[Alexis Menard (darktears)]

The patch has landed http://trac.webkit.org/changeset/60589