maemo.org Bugzilla – Full Text Bug Listing
|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 interface||Assignee:||Oleg Romashin <romaxa>|
|Status:||RESOLVED FIXED||QA Contact:||browser-bugs|
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:18.104.22.168) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7
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?
I'm happy to test Fennec, downloading it now. Will let you know how it goes...
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 :)
andre: my guess is that this is a regression from the "fix" to bug 5413.
<input value="" onchange="alert('onchange');" type="text"/> was fixed in int-148704 at 2010.01
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).