781438 - Cannot change the value of the currently selected <select> field in a mozbrowser iframe

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

STR
====

1. Launch Browser app. with B2G Desktop build or on B2G device.
2. Go to the following link to test <select>
http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_option
3. Click the <select>, the value selector overlay will show up
4. Select one of the options and click [OK]

Actual result:
 - The selected option was not set into the <select> 

Expected result:
 - The selected option would be set as the new value

Note:
 1. The same scenario could work in UI Test app.
 2. The value could not be set because we could not get the focus, it would return at:
http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/forms.js#110

Comment 1

[Gangadhar Nittala(:gnittala)]

Tested this - and confirm that this is a bug. The select doesn't show the drop-down for Volvo/Saab/Mercedes/Audi. On FF the select displays the dropdown.

Tested on Linux Mint Maya and FF 14.01
b2g version - b2g 17.0a1; latest gaia source

Comment 2

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Gangadhar,

Please informed this issue is about changing the selected option.

From my test, the options could be shown as an fullscreen overlay instead of a drop down menu.
  - B2G nightly on Mac
  http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/b2g-17.0a1.en-US.mac64.dmg

  - Latest Gaia: ed8a01e74a0c665c19ce8fc289cfe84800aa7603

Thanks for your input.

Comment 3

[Gangadhar Nittala(:gnittala)]

Attachment: Screengrab of bug# 781348

Comment 4

[Gangadhar Nittala(:gnittala)]

Rudy, confirmed that the bug happens on Linux too. Latest gaia
- cd9e40a0188709289d6724b2edee4595bac2a9c3

Still waiting on the latest b2g for Linux, but am guessing this is not an issue with b2g. I can check the source you mentioned to find out more about the root cause. Is the forms.js the main engine of display where the individual HTML elements are implemented (before Gecko renders them).

Comment 5

[:gerard-majax]

I get the same as of today's gaia and gecko git, on Nexus S. At first. Then I dunno what I did, looks like zoomming/unzoomming on the page triggered worksform ?

Comment 6

[:gerard-majax]

Attachment: Before selecting an element

This is before tapping inside the <select>, nothing is selected.

Comment 7

[:gerard-majax]

Attachment: Bus stop has been selected

The list is okay, and I select a stop then I tap 'Ok'.

Comment 8

[:gerard-majax]

Attachment: After stop has been selected

This is what I get after I tapped 'Ok' once checked an element in the list. Not only the displayed value is still the default one, but validating the form produce an error explaining no stop has been selected.

Comment 9

[:gerard-majax]

Attachment: Error stating no stop selected

When validating the form, the JS code of the website does not detect any change in the stop selection, like the <select> element had no effect.

Comment 11

[Jason Smith [:jsmith]]

Nominating per the relevant dup this is connected to.

Comment 12

[Cervantes Yu [:cyu] [:cervantes]]

FormAssistant.handleEvent() and FormAssistant.receiveMessage() are in different processes in this case. That is, saving this.previousTarget in handleEvent() can't be seen in receiveMessage(). Looks like another bug from OOP.

Comment 13

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

This issue also could be reproduced with "UI Test" app. of current Gaia, rev: cec9116d891c4da371beb958c58095e40ed2cf80.
UI Test has been changed to OOP now.

Comment 14

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Attachment: use the same messageManager which load FrameScript

previousTarget is set in a FormAssist object which create by different process, but MozKeyBoard still using globalmessagemanager to callback forms.js.
Therefore, wrong FromAssist get callback and will not have correct previousTarget to modify selected option.

Comment 15

[Eric Chou [:ericchou] [:echou]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/418d50c7c3a5

Comment 16

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/418d50c7c3a5

Comment 17

[Jason Smith [:jsmith]]

Tested on an 9/12 Otoro build, this isn't working for me via the browser. I went to bugzilla.mozilla.org --> search, selected one of the select fields, changed the value, and tried to select okay. When I hit okay, nothing happened. The prompt didn't disappear either. Any ideas?

Comment 18

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

@jsmith: I tried your test step on my Otoro (9/13 build) and <select> works fine. Could you provide adb logcat to me?

Comment 19

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: Debug log for cannot confirm the selected option

Comment 20

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Dear SC, 

This issue is not 100% reproducible, but Ian and I could reproduce this issue for several times.
When it occurs, it would generate the following error message.

E/GeckoConsole(  105): [JavaScript Error: "NS_ERROR_NOT_INITIALIZED: Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMessageSender.sendAsyncMessage]" {file: "jar:file:///system/b2g/omni.ja!/components/MozKeyboard.js" line: 69}]

FYI.

Comment 21

[Jason Smith [:jsmith]]

(In reply to Rudy Lu [:rudyl] from comment #20)
> Dear SC, 
> 
> This issue is not 100% reproducible, but Ian and I could reproduce this
> issue for several times.
> When it occurs, it would generate the following error message.
> 
> E/GeckoConsole(  105): [JavaScript Error: "NS_ERROR_NOT_INITIALIZED:
> Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED)
> [nsIMessageSender.sendAsyncMessage]" {file:
> "jar:file:///system/b2g/omni.ja!/components/MozKeyboard.js" line: 69}]
> 
> FYI.

I'll file a followup bug for this.

Comment 22

[Jason Smith [:jsmith]]

Followup bug for this is tracked in bug 791036.