734305 - Spry autosuggest drop downs do not appear properly

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect)

Description

[KLB]

Adobe provides a commonly used Ajax widget called spry auto suggest. What this widget does is provide a dynamically filtered drop down list that returns a list of options based on matches anywhere within the string value, not just the beginning of the string.  As the user types, the list narrows down to only the matching strings.

On Firefox Mobile these lists do not populate until after the "backspace" button is pressed to delete a character. Instead what should be happening is the drop down should be appearing and updating with each letter "typed" into the field.

To test this go to http://labs.adobe.com/technologies/spry/samples/autosuggest/SuggestSample.html then follow these steps:
1) Place cursor in first form field labeled "Product Name (XML)".
2) Type letter "a".  A drop down should appear that gets populated with data (it does not).
3) type a space and then press the "backspace" button. The list will now appear.

Note due to the way the Android keyboard works, you need to do this holding your device in portrait not landscape.

Comment 1

[KLB]

I've confirmed that spry auto suggest does work correctly on Android Browser and Opera Mobile. From IRC conversation, this might be caused by spry auto suggest relying on "keydown" instead of "input" at line 563 of SpryAutoSuggest.js.

Regardless, countless developers use this widget and it does work correctly on other mobile browsers. As such it should behave as intended on Firefox.

Comment 2

[KLB]

This might be related to Bug 630576

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

does this happen on desktop with an IME?

Comment 4

[KLB]

Forgive my ignorance, what does "IME" mean?

The spry autosuggest widget above works correctly on all reasonably modern desktop browsers. It also works as expected on Google's Android Browser and Opera Mobile. I haven't tested it on Safari for IOS.

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

A way to input complex glyphs. http://en.wikipedia.org/wiki/Input_method_editor

Comment 6

[Chris Peterson [:cpeterson]]

KLB, a simple IME on the Mac is the "Special Characters" window accessible from an application's "Edit" menu. It allows you to enter characters that are not available on your hardware keyboard such as '☆'.

I tested the Adobe Spry sample page on my Mac. This page seems to have the same problem on desktop Firefox. If I insert an 'A' character using the "Special Characters" window, the 'A' appears but the autosuggest menu does not open. If I manually type a 'd' character after the 'A', then autosuggest menu displays a list of products beginning with "Ad".

Comment 7

[KLB]

Okay thanks.  This is something I can not test. I don't have any IME interface (that I'm aware of) on Win7, which is my desktop environment.

Comment 8

[Chris Peterson [:cpeterson]]

This is not an Android-only bug. I can reproduce this on Mac Firefox using Mac's built-in IME.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

When we fix this bug, we need to check all keydown/keyup handlers in chrome. Please work on bug 354358 when you fix this bug. This bug report is just an actual case of it.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Bug 354358 must be fixed for D3E, however, it needs to be fixed on all tier-1 desktop platforms (Win/GTK/Cocoa) at same time. So, the change must be big. However, the merit isn't so big. Basically, keydown/keyup events shouldn't be used for text input handling because some text input devices like hand-writing device don't cause these events. HTML5 input event is the best event for handling text input event. It's fired even during composition and after the editor actually modified.

So, I think Adobe should fix this issue on their side. I'd like to suggest that this bug should be changed to evangelist bug.

Comment 11

[Chris Peterson [:cpeterson]]

Moving this bug to Tech Evangelism: Adobe's Spry Auto Suggest Widget should use HTML5 input for text handling.

Comment 12

[KLB]

Moving this to evangelism and saying it needs to be fixed by Adobe is the wrong answer to this bug. Even if it is Spry's fault for using a key down instead of HTML5 input this still needs to be fixed in Firefox because:

1) It works correctly with other mobile browsers and all desktop browsers (including Firefox).

2) It is highly likely that other JavaScripts (both "canned" like Spry Autosuggest and home rolled) also rely on key down rather than input events.

3) Even if Adobe provided an update to fix this issue, which I highly doubt they would do, there will be countless existing websites that will never update their Spry code and thus remain broken on Firefox Mobile.

4) Because other mobile browsers do provide key down events, developers will say it works on other mobile browsers so good enough or may not even realize that Firefox Mobile does not provide key down response.

5) Users will have a poor user experience with Firefox Mobile because their favorite site does not work correctly on Firefox Mobile and simply use a different mobile browser like Opera Mobile, Android Browser, Chrome Mobile or Dolphin.  To break into the mobile browser Market, Firefox needs to handle issues like this as well as other browsers.

I personally have a client for whom I've been building a web based database application for a few years now that is being optimized for mobile devices.  I will not be able to convince them to switch over to Firefox Mobile if this issue is not resolved. But if it were resolved, they would probably switch over in a heartbeat because they don't like Android Browser.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Please note that the different behavior is really our bug (D3E allows our behavior, though), see bug 354358, we don't deny the fact. However, The bug's priority should be lower than other D3E key/IME bugs because it doesn't make sense to use physical key state events (keydown/keyup) during composition, so, most web developers will not become happy by the fix.

On the other hand, if Adobe handles only keydown event, it's not accessible from non-keyboard input device. Therefore, we should tell the issue to Adobe in this case.

And I think that your clients should be able to add work around for their UI instead of updating its backend. Even during composition (between compositionstart and compositionend), Gecko fires input events. It can be handled by |window.addEventListener("input", function (event) {}, false);| for all input elements.  Then, you can dispatch an untrusted keydown event from the handler to the input event's target. I *guess* it would kick the spry's handler.

Comment 14

[KLB]

In the case of SpryAutoSuggest.js the solution is as simple as replacing the single instance of "keydown" with "input". I just tried it and it worked just fine. So if Adobe could be convinced by someone from Mozilla to make this single change it should resolve the issue going forward.  I agree that in an ideal world scripts should be using "input" instead of "keydown" but Firefox Mobile should still respond to "keydown" just do deal with legacy sites and sites that don't take mobile browsers into account for the sake of providing a better user experience.

Comment 15

[Chris Peterson [:cpeterson]]

My fix for bug 687717 makes this problem go away for Fennec users inputting Latin characters using VKB.

Comment 16

[JP Rosevear [:jpr]]

(In reply to Chris Peterson (:cpeterson) from comment #15)
> My fix for bug 687717 makes this problem go away for Fennec users inputting
> Latin characters using VKB.

Does this mean its actually our issue?  If so, should we dupe it?

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to JP Rosevear [:jpr] from comment #16)
> (In reply to Chris Peterson (:cpeterson) from comment #15)
> > My fix for bug 687717 makes this problem go away for Fennec users inputting
> > Latin characters using VKB.
> 
> Does this mean its actually our issue?  If so, should we dupe it?

See comment 10 and comment 13.

Comment 18

[Karl Dubost💡 :karlcow]

Now redirected to 
http://blogs.adobe.com/dreamweaver/2012/08/update-on-adobe-spry-framework-availability.html

This is INVALID. Design has changed.