Bug 8362 (int-148704)

Summary: Some combination of Maemo 5 + Nokia N900 results in improper onChange callbacks in the maemo browser
Product: [Maemo Official Applications] Browser Reporter: Nick Thomas <nick>
Component: User interfaceAssignee: Oleg Romashin <romaxa>
Status: RESOLVED FIXED QA Contact: browser-bugs
Severity: normal    
Priority: Unspecified CC: andre_klapper, tuukka.tolvanen
Version: 5.0/(2.2009.51-1)   
Target Milestone: 5.0/(10.2010.19-1)   
Hardware: N900   
OS: Maemo   

Description Nick Thomas (reporter) 2010-01-21 16:09:29 UTC 
SOFTWARE VERSION: Nokia N900 / Maemo 5 / 2.2009.51-1.203.2

EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. Browse to any site with an <input onchange='alert("Moo");'> (or similar)
element using the Maemo 5 browser
2. Type a single character into the input field using the hardware keyboard

EXPECTED OUTCOME:
Nothing. The code in onchange shouldn't be executed until the field loses focus
(i.e., tabbing to another field or tapping elsewhere on the page)

ACTUAL OUTCOME:
The code in the onchange handler is executed immediately after the first button
is pressed. If this is something like form.submit(); on a login form, this
makes the form containing the input unusable since (unless your password is one
character long!)

REPRODUCIBILITY: Always


EXTRA SOFTWARE INSTALLED: None

OTHER COMMENTS:
The W3C states that onchange callbacks should only be executed once the field
has lost focus, if the contents have changed since the field gained focus. I
suspect that what's happening in this case is that the field /is/ losing focus
(so the browser is technically compliant), but that the loss of focus is
inappropriate (because I've not finished typing yet!). I'm assigning this to
the browser since I think that's most appropriate - feel free to bounce to the
platform people if they're the ones who should deal with it.

For an example of an unusable site, see http://clueless.aaisp.net.uk/

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.7)
Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7
Comment 1 Andre Klapper maemo.org 2010-01-21 16:40:42 UTC 
Thanks for reporting this.
So this is not covered by the fix of bug 5413...
Any chance to test how Firefox Mobile (Fennec) behaves here?
Comment 2 Nick Thomas (reporter) 2010-01-21 17:26:11 UTC 
I'm happy to test Fennec, downloading it now. Will let you know how it goes...
Comment 3 Nick Thomas (reporter) 2010-01-21 17:39:04 UTC 
Fennec (current version downloaded from firefox.com/m ) doesn't contain this
bug, making it seem less likely that the bug is caused by the platform (typing
on the keyboard making the WM shift focus elsewhere, for instance), and more of
an internal-to-MicroB issue, I guess.

For reference, http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.3
states:

The onchange event occurs when a control loses the input focus and its value
has been modified since gaining focus. This attribute applies to the following
elements: INPUT, SELECT, and TEXTAREA.

I'm happy to use Fennec instead of MicroB, so if you're thinking about
replacing MicroB with it at any time in the nearish future, there's probably
not that much point trying to fix it... your call :)
Comment 4 timeless 2010-01-21 17:58:07 UTC 
andre: my guess is that this is a regression from the "fix" to bug 5413.
Comment 5 tuukka.tolvanen nokia 2010-01-23 03:53:08 UTC 
<input value="" onchange="alert('onchange');" type="text"/> was fixed in
int-148704 at 2010.01
Comment 6 Andre Klapper maemo.org 2010-03-15 20:51:52 UTC 
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).