========
https://hg.mozilla.org/integration/gaia-central/rev/fe9fdd5d8bb5
Author: John Ford <john@johnford.info>
Desc: Revert "Merge pull request #12892 from comoyo/value_selector_inputcontext"
This reverts commit 4fb5a545dc2dc6d89e6f912f787e019a770d907c, reversing
changes made to fa366f051e657d49406dfebc433ccd69ea62353d.
========
https://hg.mozilla.org/integration/gaia-central/rev/f938b8542d09
Author: lissyx <lissyx+github@lissyx.dyndns.org>
Desc: Merge pull request #13088 from lissyx/bug923577
Bug 923577 - Ensure that we remove icons of hidden roles r=crdlc
========
https://hg.mozilla.org/integration/gaia-central/rev/778c88285c4a
Author: Alexandre Lissy <lissyx+github@lissyx.dyndns.org>
Desc: Bug 923577 - Ensure that we remove icons of hidden roles r=crdlc
When installing an application that is hidden, we have to make sure,
when updating the icon, that we remove it. This case happens especially
with packaged role system app, like, in this bug, a ringtones app. We
end up creating a temp icon (because we only have a updateManifest at
that time and cannot decide the role of the app) while downloading,
which is not removed once the app is finally installed.
In bug 921928, the user places a call and then tries to do other actions
(calls, SMS, contacts, ...) with actions very close to the attention
screen. When trying to do those other actions, event fluffing is
prioritizing the attention screen rather than user apps.
---
layout/base/PositionedEventTargeting.cpp | 10 ++
layout/base/tests/Makefile.in | 2 +
.../bug921928_event_target_iframe_apps_oop.html | 8 +
.../base/tests/test_event_target_iframe_oop.html | 178 +++++++++++++++++++++
4 files changed, 198 insertions(+)
create mode 100644 layout/base/tests/bug921928_event_target_iframe_apps_oop.html
create mode 100644 layout/base/tests/test_event_target_iframe_oop.html
========
https://hg.mozilla.org/integration/gaia-central/rev/a1f4dbe091d7
Author: Ian Liu <iliu@mozilla.com>
Desc: Merge pull request #12971 from ian-liu/bluetooth/Bug915584_revise_flow_for_receiving_file_without_SDCard
Bug 915584 - [Bluetooth][Contacts] Receiving a contact via bluetooth when the device does not have SD Card flow differs from the expected, r=@alivedise
========
https://hg.mozilla.org/integration/gaia-central/rev/170ec7f9d9a9
Author: ian-liu <iliu@mozilla.com>
Desc: Bug 915584 - [Bluetooth][Contacts] Receiving a contact via bluetooth when the device does not have SD Card flow differs from the expected
========
https://hg.mozilla.org/integration/gaia-central/rev/d3308d368858
Author: Julien Wajsberg <felash@gmail.com>
Desc: Revert "Merge pull request #12802 from caiolima/bug-815093"
This reverts commit 47b3bdf7a6e9396db6e09ac0453f782953ceda7a, reversing
changes made to 1d832634550de25526eaf93137940f9fd73a4c7f.
========
https://hg.mozilla.org/integration/gaia-central/rev/33b06ed662ee
Author: Arthur Chen <crh0716@gmail.com>
Desc: Revert "Bug 909689 - Set data connection text based on the network mode and the existence of calls"
This reverts commit d505b37f2e856d0cf7c7cd5b37c02eec44f06b7d.
========
https://hg.mozilla.org/integration/gaia-central/rev/8e5ab4582834
Author: evelynhung <jj.evelyn@gmail.com>
Desc: Merge pull request #13024 from MBRSL/eng-mode
Bug 913385 - Add Hardware tests mode r=evelyn,zac
========
https://hg.mozilla.org/integration/gaia-central/rev/7c55c55ae7f6
Author: Tom Jao <tjao@mozilla.com>
Desc: Bug 913385 - Add Hardware tests mode r=evelyn
This patch organize old tests into API and UI parts, and add new Hardware tests.
Also, there are some minor fixes on existing tests.
HW tests mode provide the following tests:
Audio loop
Battery
Bluetooth
Camera
Headphone
LCD
Physical keys
Ringer
SDCard
Sensors
Touch screen
Vibrator
Truncated some number of revisions since the previous bump.
========
https://hg.mozilla.org/integration/gaia-central/rev/373644db99ce
Author: Rick Waldron <waldron.rick@gmail.com>
Desc: Bug 920546 - [Messages] Short-term fixes for the recipient panel r=julienw
https://bugzilla.mozilla.org/show_bug.cgi?id=920546
- Apply new "invalid recipient" indicator style
- Decouple searchContact from list display
- Create ThreadUI.listContact(...)
- Create ThreadUI.validateContact(...)
- Adds two level validation:
- Is the entry questionable?
- This kicks off a silent search for matching contacts
- If there are one or more matches, use the first to create a Recipient
- Is the entry invalid?
- This state is reached if no contacts could be found
for the typed value.
- Prevents enableSend
- Prevents "export" of recipient entry at Send
(when mixed with multiple valid recipients)
- Refactor Utils.getContactDisplayInfo logic
- Adds tests for enableSend
- Adds tests for questionable Recipient detection.
Changes, post review:
> Bug 1:
> - enter a bogus recipient, press enter to "accept" it
> - press backspace => the cursor is correctly inside the contenteditable element, but it's still "red" and the keyboard is hiding
Fixed by adding CSS rules:
[contenteditable=false].attention
[contenteditable=true].attention
---
> Bug 2:
> - with the recipient light workload, that has a "Adam L. Card" contact
> - typing exactly "Adam L. Card" => no match
> - typing "Adam Card" => match
Yep, this has always been true. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=860804
---
> Bug 3:
> - add text in the composer
> - add a bogus contact => the send button is enabled, should be disabled
Fixed by being more explicit in enableSend:
Set hasRecipients to true based on the following conditions:
1. There is a valid recipients object
2. One of the following is true:
- The recipients object contains at least 1 valid recipient
- OR -
- There is >1 character typed and the value will not
evaluate to a NaN
Signed-off-by: Rick Waldron <waldron.rick@gmail.com>
For each profile manager, we'd like to make sure that the data member of
mController is nulled out before invoking the callback function. Because, in the
callback function, we continue to handle the next connect/disconnect request,
and we'd like to null out mController of previous request before handling the
new one.
