The NSAccessibilityHelpAttribute is being repurposed here, too, to expose the information other platforms call the Accessible Description rather than the Accessible Help tag, which traditionally referred to a connection to a Windows help file in old MSAA.
--HG--
extra : commitid : It2o0CiKUxb
extra : rebase_source : 06f20dcafbb937f103a3ed3de5681576518c037e
This allows WebDriver compatibility to create valid URI.
--HG--
extra : commitid : 7JjQgqwKr8P
extra : rebase_source : 30e59c18b69ab404608c6b44f1dc11742b95ac78
This avoids a real event being dropped in favour of a synthesized event via IPDL compression, which is important because synthesized events don't generate 'mousemove' DOM events.
--HG--
extra : rebase_source : 711341f7ae50583498854993028bbd9e1b1299cc
extra : source : c0e8553911e54232f060bbb284f936d81f73f411
It has previously been increased for a specific test, but we have found
another test that needs it increased. Rather than increasing it for
individual tests, increase it for all tests.
--HG--
extra : rebase_source : 1e32b0c851bb138d1ed247fea72312c09380266c
extra : source : fb4d8f6db088a2da12d01403280b959d176fee0a
This avoids excessive amounts of test data accumulating which can slow tests down.
As part of this change, the pref for enabling the logging was made 'Live'.
--HG--
extra : rebase_source : 0abbf10b3e3b3a67bbb810d4554a7b55bfc6fd66
extra : source : d7bac1264671c0a10da034d6d9b08f01235ebdb3
========
https://hg.mozilla.org/integration/gaia-central/rev/0164a51c5b86
Author: Ryan VanderMeulen <ryanvm@gmail.com>
Desc: Merge pull request #31109 from cr/pctofix
Bug 1181571 - Fix lockscreen delay issue
========
https://hg.mozilla.org/integration/gaia-central/rev/87828a5b67d4
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Fix TypeError: this.emergencyCallBtn is null
========
https://hg.mozilla.org/integration/gaia-central/rev/c07276bb5364
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Overhaul tests for new internal InputPad logic
========
https://hg.mozilla.org/integration/gaia-central/rev/4ec9fe1337dc
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Finalizing tests
Tests now working. Solved by creating a setTimeout stub that forces
synchronicity. Also removed onPasscodeValidationFailed trigger check
on wrong pass code, because I can't make the promise resolve before
the test ends without code changes in the test subject.
========
https://hg.mozilla.org/integration/gaia-central/rev/caf1b7db97bd
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Add comment on event flow
========
https://hg.mozilla.org/integration/gaia-central/rev/230ebd40b450
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Fix comment
========
https://hg.mozilla.org/integration/gaia-central/rev/4328ada81707
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Add test prototypes for pass code handling
========
https://hg.mozilla.org/integration/gaia-central/rev/87581a852a13
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Fixing lockscreen delay bypass by rewriting core logic
This is fixing bug 1181571 where lockscreen delay on repeated pass code
failure could be trivially bypassed by pressing the home button. The
faulty behavior was caused by a limitation of the previous architecture
which was only making the delay occurr *after* a wrong pass code had
been entered. Consequently, whenever the input pad would be restarted,
like after closing it with the home button or when a screen timeout
occurred, the pending delay would not persist and pass code entry would
be accepted right away.
The fix made it necessary to rewrite parts of lockscreen's messaging
and state handling. Previous changes in architecture caused pass code
failure counting and delay timer handling to be maintained in two
places: in LockScreen (for pass code checking) and in LockScreenInputPad
(for displaying error state to the user). Logic error even caused the
two states to get out of sync under certain conditions.
Now state and timeout related to pass code checking are maintained
exclusively by LockScreen, which signals LockScreenInputManager with
three distinct messages of failure (on wrong pass code), reset (after
error delay has passed), and success (on correct pass code).
LockScreenInputPad now is always aware of a passcode error delay ongoing
in LockScreen, every UI update is rendered according to this state, and
key input is ignored when necessary.
