Description: When the user has SIM PIN enabled, restarts the device and enters the wrong PIN, the buttons "Skip & OK" overlaps the "Enter SIM PIN" input field. Prerequisites: SIM PIN enabled Repro Steps: 1) Updated Buri to Build ID: 20140220040203 2) Enable the SIM PIN in Settings 3) Restart the device 4) Enter the wrong SIM PIN when prompted to enter the SIM PIN. 5) Tap on the input field Actual: The buttons "Skip & OK" overlaps the "Enter SIM PIN" input field. Expected: The "Enter SIM PIN" input field must be visible to the user Environmental Variables Device: buri 1.4 MOZ RIL Build ID: 20140220040203 Gecko: https://hg.mozilla.org/mozilla-central/rev/660b62608951 Gaia: 6e71ab4da1b08586ea0c758edb7aa199ee34cd2f Platform Version: 30.0a1 Firmware Version: V1.2-device.cfg Repro frequency: 100% See attached: Screenshot, logcat Optional workarounds that may have been identified: By entering any number from the keyboard makes the entry field visible again

This issue reproduces on buri 1.3 Environmental Variables Device: Buri v 1.3.0 Mozilla RIL Build ID: 20140220004003 Gecko: https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/32fd5d798477 Gaia: a43904d9646109b48836d62f7aa51e499fbf4b2e Platform Version: 28.0 Firmware Version: v.1.2-device.cfg The buttons "Skip & OK" overlaps the "Enter SIM PIN" input field.

Does this reproduce on 1.1?

This issue does not reproduce on buri v1.1 Environmental Variables: Device: Buri V1.1 MOZ RIL Build ID: 20140218041202 Gecko: https://hg.mozilla.org/releases/mozilla-b2g18/rev/d7f2811943d1 Gaia: c5cb252e5d1aa45d14f3a2ea182e73e2271e4496 Platform Version: 18.1 Firmware Version: V1.2-device.cfg The "Enter SIM PIN" input field displays correct.

I thought we fixed this. Apparently not.

The earliest that the bug repros is on the first Aurora build (12/10), and does not repro on the last Central build (12/9). No repro Build ID: 20131209053402 Gecko: http://hg.mozilla.org/mozilla-central/rev/9f12a9fab080 Gaia: 1d45d1dc3201059d5c8f2efdeb92c04576d8e161 Platform Version: 28.0a1 Firmware Version: V1.2-device.cfg Repro Build ID: 20131210004003 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/e0c328d99742 Gaia: 3452fbdb5e1bed0cd27cc6173136537a03e8072f Platform Version: 28.0a2 Firmware Version: V1.2-device.cfg

It looks like we fixed this partially in bug 951774 (https://github.com/mozilla-b2g/gaia/commit/4062fea3d44f66d2927af884b7b58e1e9bf36c34). However, it seems that the added margin only works *before* we add the error message. I think we need a more robust solution, like the keyboard API being aware of the OK and SKIP button height, and scrolling to the form input location with this in mind.

Dale, since you worked on bug 951774, would you be able to take a look at this as well?

I can take it, The buttons need to not be fixed to the bottom like that, otherwise there will always be problems, I didnt want to to too intrusive a fix but we should do it properly, I have an idea of how to get it tests I think as well

I thought of the idea while I was needinfoing gareth to ask him how to test it :) (although if you have ideas / pointers to tests that would be awesome)

Hey Dale! I think getting the absolute offsets, heights, and widths of the two elements (see https://github.com/sstephenson/prototype/blob/master/src/prototype/dom/layout.js#L1099 for a nice method for absolute offsets) on the page and then checking if there's any overlap is probably the best way? Maybe there's something smarter though.

Sorry for taking a while on this, getting a test written was a nightmare. I started looking into why scrollIntoView was working, but being inside the system app / in process there are all sorts of bugs, we most definitely want to move the dialogs out of process right? in the meantime I think this is the cleanest / most reliable fix. I have one minor issue to finish up with the test, but I figured it shouldnt block review, I will remove the .wait

Comment on attachment 8385355 [details] https://github.com/mozilla-b2g/gaia/pull/16828 r+ with nit. But globally this solution sounds like a workaround...

Its a definite workaround, am I right in thinking we should be moving these / all ui out of process so we dont have to deal with confusing code paths for events. Since this is a blocked and the test is being a nightmare, landing with test disabled, nit fixed and filing a follow up to reenable test

Landed https://github.com/mozilla-b2g/gaia/commit/fa25ec9e9491388beee916b35ad3c59cbfee2f30 and filed follow up https://bugzilla.mozilla.org/show_bug.cgi?id=979861

When this is ready for uplift to v1.3, please request approval-gaia-v1.3 on the patch. Thanks!

Reverted this for failures in system/test/unit/sim_settings_helper_test.js: https://tbpl.mozilla.org/php/getParsedLog.php?id=35660768&tree=B2g-Inbound https://github.com/mozilla-b2g/gaia/commit/05337d2ce75651550892ca883030548ed5f7d6aa

Apologies, was a disabled test on a green travis run https://github.com/mozilla-b2g/gaia/pull/16911 fixed up and will reland on green Working to enable the tests seperately

Dale, seems you push the new branch to gaia https://github.com/mozilla-b2g/gaia/tree/975161 ?

Keep doing that, deleted, apologies

Please request approval-gaia-v1.3 on this patch when this is ready for uplift.

Hey ya, what do we move mock for testing purpose into /js in the patch?

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #21) > Please request approval-gaia-v1.3 on this patch when this is ready for > uplift.

> Hey ya, what do we move mock for testing purpose into /js in the patch? Because otherwise the mock was inaccessible to the integration tests which builds a non production profile, there are a few other mocks in js/ for the same reason > Please request approval-gaia-v1.3 on this patch when this is ready for uplift. Sorry figured that was on release managers, will do now

Comment on attachment 8385355 [details] https://github.com/mozilla-b2g/gaia/pull/16828 NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): [User impact] if declined: User may not see inputs they need to [Testing completed]: Integration test included although disable by default [Risk to taking this patch] (and alternatives if risky): little [String changes made]: none

This needs a branch patch for uplift to v1.3.

Apologies for the delay, I was on PTO, should have changed my buzilla name to say that Uplifted a branch patch to v1.3 https://github.com/mozilla-b2g/gaia/commit/587888b23a2f4b8dad8750cede1e17a5bc53369d