Closed Bug 460128 Opened 16 years ago Closed 16 years ago

autocomplete suggestions will dynamically use form input, including password fields

Categories

(Core :: Widget: Gtk, defect)

Other
Maemo
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.2a1

People

(Reporter: jmaher, Assigned: tonikitoo)

References

Details

Attachments

(1 file, 2 obsolete files)

when entering data into a form on the nokia there is an autocomplete/suggest mechanism which is designed to make entering text much easier. This data is dynamic and uses values from text entered in online forms (username, firstname, etc...). The problem is that it will add the text value of the password entered into a webform. We need to find a method where we can tell the Nokia device to ignore password field text.
Assignee: nobody → tonikitoo
Status: NEW → ASSIGNED
1) autocomplete/suggest mechanism will probably be disabled (I suggest it to be settable through a preference) using gconf - bug 2) hildon provide some bits to be tweaked to avoid the completion content to be shown, what is probably something good to do for this bug.
Blocks: 455339
Attachment #347894 - Flags: review?(roc)
oleg, could you also take a look ?
OS: Mac OS X → Linux (embedded)
Hardware: PC → Other
+ + // Bug 460128: it is not desired that the hildon's autocomplete mechanism + // displays user previous entered passwds, so lets make completions invisible + // in this cases. Don't mention the bug number here. People can get it from the commit comment. What's this MULTILINE option you're adding/removing? We do reach this code for single-line inputs.
Attached patch patch v0.3 (obsolete) (deleted) — Splinter Review
> Don't mention the bug number here. People can get it from the commit comment. removed > What's this MULTILINE option you're adding/removing? We do reach this code for single-line inputs. roc, there is a short description about those flags here http://maemo.org/api_refs/4.0/gtk/GtkIMContext.html#HildonGtkInputMode This MULTILINE bit is actually one more bad name from the API. In practical terms, what it does is let the input method to know if the widget the imcontext is attached to *can* supports multiple lines of text when input. So, it works for both single-line and multi-line inputs here.
Attachment #347894 - Attachment is obsolete: true
Attachment #347898 - Flags: review?(roc)
Attachment #347894 - Flags: review?(roc)
Can you explain why we should add MULTILINE for a single-line input? Would there be any benefit to *not* adding MULTILINE for a single-line input?
> Can you explain why we should add MULTILINE for a single-line input? as I told, MULTILINE is not very meaningful for this flag: it only tells that the input (or whatever) can accept multiple lines, but not necessarily have them. As there is not a corresponding SINGLELINE flag, we end up forced to use it. For one more reference, search for "update_im_context_mode" in https://garage.maemo.org/svn/browser/mozilla/trunk/microb-eal/src/gmozillaengine.c (microb browser - built in mozilla-based browser on maemo). > Would there be any benefit to *not* adding MULTILINE for a single-line input? No. the patch would actually fail to do the job.
(In reply to comment #7) > > Can you explain why we should add MULTILINE for a single-line input? > > as I told, MULTILINE is not very meaningful for this flag: it only tells that > the input (or whatever) can accept multiple lines, but not necessarily have > them. I don't understand. > > Would there be any benefit to *not* adding MULTILINE for a single-line input? > > No. the patch would actually fail to do the job. Why?
Right, let me try again: In http://maemo.org/api_refs/4.0/gtk/GtkIMContext.html#HildonGtkInputMode there are the bit-flags we have available in order to tweak the way the maemo users interact with the keyboard (either the virtual or the physical one). Using these it is possible to show the virtual keyboard only with letters, numbers, and so on (see HILDON_GTK_INPUT_MODE_ALPHA , HILDON_GTK_INPUT_MODE_NUMERIC and friends, for example). However, only two of those matter if we are talking about the word completion widget the maemo platform has: * HILDON_GTK_INPUT_MODE_MULTILINE * HILDON_GTK_INPUT_MODE_INVISIBLE Why only these two ? Mainly because they are the ones that can be adjusted depending on the widget that holds the im_context at a given time (yeah,the API is limited so that it is not possible, for example, to explicitly specify if the widget that owns the im_context is single or multiline (no HILDON_GTK_INPUT_MODE_SINGLELINE option or similar available). So if the widget is either single or multiline, the HILDON_GTK_INPUT_MODE_MULTILINE can be used in the same way if we are talking about the word completion widget (the issue of this bug): * HILDON_GTK_INPUT_MODE_MULTILINE will show/echo any user input to the completion widget (no matter if it is a single or multiline widget). * HILDON_GTK_INPUT_MODE_INVISIBLE will not Does it make things clear, roc ?
Not quite. What is the difference between setting HILDON_GTK_INPUT_MODE_MULTILINE and not setting it? I would have assumed that if HILDON_GTK_INPUT_MODE_MULTILINE was not set, that would mean the widget was single-line.
Attached patch patch v0.4 (deleted) — Splinter Review
sorry about the noise on the multiline stuff. it should not really care about it. Invisible is only what we want.
Attachment #347898 - Attachment is obsolete: true
Attachment #348136 - Flags: review?(roc)
Attachment #347898 - Flags: review?(roc)
thanks roc. checkin-needed added.
Keywords: checkin-needed
Blocks: 401821
cc'ing sgautherie.bz@free.fr ping check-in
(In reply to comment #13) > cc'ing sgautherie.bz@free.fr Please, don't cc me: 'checkin-needed' is enough. > ping check-in And Fennec-specific checkins are very low (as in "not") in my priorities. (You'd better ask someone who actually "works" on Fennec.)
Attachment #348136 - Flags: superreview?(roc)
Attachment #348136 - Flags: superreview?(roc) → superreview+
how could we get it into 1.9.1 too, once it targets fennec, that is in that branch still ? mark, does it make sense ?
Once the patch bakes on trunk for a few days we can request approval for 1.9.1 The plan is for Fennec to use 1.9.1, so landing on the branch is a priority. I can't land this patch, but blassey or stuart could.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Component: General → Widget: Gtk
Keywords: checkin-needed
Product: Fennec → Core
QA Contact: general → gtk
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: