The call to setResolution has (I believe) not been needed since bug 732971. Prior
to that resolutions used to be applied on the root document in Fennec, and so
browser.js would have to reapply the desired resolution on every tabswitch.
After that bug, the resolution was saved on the content documents for each tab
and so browser.js no longer needed to reapply the resolution. Until recently
doing this was redundant but harmless.
With bug 1180267 though the browser.js code that tracks the resolution may have
the wrong resolution initially, because that is determined in C++ code. Only
after the Java-side code process the setFirstPaintViewport message and sends
that information to browser.js does everything have the correct resolution. In
the case where a tab loaded in the background is brought into the foreground, the
tab-selected code runs before the setFirstPaintViewport code, and therefore uses
an incorrect resolution. This then screws up the viewport clamping code and causes
the page to get scrolled.
The intent of this check is to avoid setting the same margins more than once.
However this is redundant because the code in nsLayoutUtils::SetDisplayPortMargins
already has an equivalent check. Further, this code is wrong because it stores
the old margins per-tab, and so once a new document is loaded the margins may be
the same as "before" but they apply to a different element. In order to be correct
the check would have to track the target element as well as the margin values,
but it's easier to just get rid of this and let nsLayoutUtils handle it.
========
https://hg.mozilla.org/integration/gaia-central/rev/fc4f98456307
Author: Borja Salguero <borjasalguero@users.noreply.github.com>
Desc: Merge pull request #31721 from borjasalguero/fix_detail_color
Bug 1201052 - After updating a contact the statusbar turns from blue …
========
https://hg.mozilla.org/integration/gaia-central/rev/85ad5ec27b81
Author: borjasalguero <borja.salguero@gmail.com>
Desc: Bug 1201052 - After updating a contact the statusbar turns from blue to grey r=arcturus
========
https://hg.mozilla.org/integration/gaia-central/rev/dbc91f258493
Author: Carsten Book <tomcat@mozilla.com>
Desc: Merge pull request #31060 from cr/immediatelockfix
Bug 1186100 - Making 'ls.lock-immediately' lock immediately. r=gweng
========
https://hg.mozilla.org/integration/gaia-central/rev/70e743abb1e1
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Request lock from state manager instead of direct .lock
With the new lockscreen state manager in place, the 'lock-immediately'
must send 'lockscreen-request-lock' event instead of using the .lock
method directly. Else, state manager will lose track of lock state.
========
https://hg.mozilla.org/integration/gaia-central/rev/3e208d1a2892
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Adapted .checkPassCodeTimeout() argument
========
https://hg.mozilla.org/integration/gaia-central/rev/de631d762fb4
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Move resetTimeoutForcibly close to its relatives
========
https://hg.mozilla.org/integration/gaia-central/rev/5af9b3161dba
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Port settings observer to SettingsListener.observe()
The only reason for this is consistency with the rest of the file. Also
this makes writing tests slightly more pleasing.
========
https://hg.mozilla.org/integration/gaia-central/rev/46af653554dd
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Add and fix lock-immediately tests
This extends lockscreen_test.js with two new tests that check whether
resetting timeouts will trigger pass code check, and whether lock-immediately
triggers timeout reset.
This also fixes the old lock-immediately test which didn't trigger the
observer callback and effectively tested whether a locked lockscreen would be
locked, which resulted in a broken test that never fails.
========
https://hg.mozilla.org/integration/gaia-central/rev/5cac6a991399
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Moving 'ls.lock-immediately' fix to lockscreen.js
Moved timestamp reset call from LockScreenWindowManager.'s
'lockscreen.lock-immediately' handler to LockScreen's, fully
encapsulating the fix for bug 1186100 in lockscreen.js.
Added inline comments on bugfix rationale.
========
https://hg.mozilla.org/integration/gaia-central/rev/12b4d204c4d6
Author: Christiane Ruetten <cr@mozilla.com>
Desc: Making 'ls.lock-immediately' lock immediately
This fixes a bug where 'lockscreen.lock-immediately' as sent by
FindMyDevice doesn't lock the device immediately with a passcode
when a pass code timeout has been set.
On unlock, LockScreen.checkPassCodeTimeout() only asks for the pass code
when either .fetchLockedInterval() or .fetchUnlockedInterval() exceed
the pass code timeout.
Setting both _lastLockedTimeStamp and _lastUnlockedTimeStamp to
something deep in the past will enforce pass code entry on unlock and
avoid a potential race condition.
========
https://hg.mozilla.org/integration/gaia-central/rev/199837e577da
Author: Rex KM Lee <rexboy@mozilla.com>
Desc: Merge pull request #31707 from Fischer-L/bug_1189221-flat-out-upper-left-icons
Bug 1189221 - [TV 2.5][Home] Separate upper left corner icons into each individual icons with only 1 layer. r=Fischer
========
https://hg.mozilla.org/integration/gaia-central/rev/41698cf449f2
Author: Fischer.json <foxbrush@Fischerjsons-MacBook-Pro.local>
Desc: Bug 1189221 - [TV 2.5][Home] Separate upper left corner icons into each individual icons with only 1 layer
