searching for reviewer(margaret)
ca47ede31df38a016126495afdb28674ce2ea3fd: Bug 1265742 - Update Google search plugin; r=margaret, a=lizzard
Michael Kaply <mozilla@kaply.com> - Tue, 19 Apr 2016 09:21:38 -0500 - rev 398012
Push 25443 by felipc@gmail.com at Mon, 08 Aug 2016 17:54:21 +0000
Bug 1265742 - Update Google search plugin; r=margaret, a=lizzard
a5b1d40aa344f53215c8b76c03bbe9ea6b77717d: Bug 1283582 - Stop displaying the context menu in Fennec if web content did a preventDefault on the event. r=margaret, a=gchang
Kartikaya Gupta <kgupta@mozilla.com> - Tue, 05 Jul 2016 10:09:38 -0400 - rev 391710
Push 23905 by mozilla@buttercookie.de at Fri, 22 Jul 2016 19:26:20 +0000
Bug 1283582 - Stop displaying the context menu in Fennec if web content did a preventDefault on the event. r=margaret, a=gchang MozReview-Commit-ID: 4JQwXNfJxip
af923f4926e7606c93218467f4de253c9a2bc783: Bug 1258549 - Upgrade fennec support links. r=margaret, a=sylvestre
Andrzej Hunt <ahunt@mozilla.com> - Fri, 03 Jun 2016 11:10:26 -0700 - rev 391553
Push 23905 by mozilla@buttercookie.de at Fri, 22 Jul 2016 19:26:20 +0000
Bug 1258549 - Upgrade fennec support links. r=margaret, a=sylvestre MozReview-Commit-ID: 2fgrkbppx5g
1c0fa79f1afdbba4a6488d887aa3a34a25af52a1: Bug 1279306 - Use the production push server URL on Android. r=margaret a=gchang
Kit Cambridge <kcambridge@mozilla.com> - Thu, 09 Jun 2016 17:13:39 -0700 - rev 391545
Push 23905 by mozilla@buttercookie.de at Fri, 22 Jul 2016 19:26:20 +0000
Bug 1279306 - Use the production push server URL on Android. r=margaret a=gchang MozReview-Commit-ID: Fy347g00Lx0
af0f02e07f6aebcbc33ad9a775e66c794f9010a3: Bug 1238128 - Ensure that the details passed to WebChannelMessageToChrome is a string, with a whitelist for messages from existing users r=Margaret,markh,MattN
Thom Chiovoloni <tchiovoloni@mozilla.com> - Tue, 12 Jul 2016 19:34:41 -0400 - rev 387611
Push 23013 by masayuki@d-toybox.com at Thu, 14 Jul 2016 12:27:17 +0000
Bug 1238128 - Ensure that the details passed to WebChannelMessageToChrome is a string, with a whitelist for messages from existing users r=Margaret,markh,MattN MozReview-Commit-ID: DpdJ5bUcBdQ
0f717e101c78709aa6e5b0c29826c856a20d388b: Bug 1276686 - Prevent selection when tapping on reader mode toolbar. r=margaret, a=gchang
Ray Lin <ralin@mozilla.com> - Fri, 03 Jun 2016 22:38:39 +0800 - rev 387413
Push 22943 by michael.l.comella@gmail.com at Wed, 13 Jul 2016 21:34:52 +0000
Bug 1276686 - Prevent selection when tapping on reader mode toolbar. r=margaret, a=gchang MozReview-Commit-ID: 9A4aZBUTKf6
24787f5d46cff354208970c6b366b268a44f365d: Bug 1283582 - Stop displaying the context menu in Fennec if web content did a preventDefault on the event. r=margaret, a=gchang
Kartikaya Gupta <kgupta@mozilla.com> - Tue, 05 Jul 2016 10:09:38 -0400 - rev 387382
Push 22943 by michael.l.comella@gmail.com at Wed, 13 Jul 2016 21:34:52 +0000
Bug 1283582 - Stop displaying the context menu in Fennec if web content did a preventDefault on the event. r=margaret, a=gchang MozReview-Commit-ID: 4JQwXNfJxip
ec92630e4c635ef1fbaac6115c6a123de1fd5d28: Bug 1281536 - remove reader mode telemetry that's out of date, extend two existing probes, r=margaret,data-r=bsmedberg
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Fri, 24 Jun 2016 15:39:23 +0100 - rev 385042
Push 22407 by gijskruitbosch@gmail.com at Thu, 07 Jul 2016 15:38:49 +0000
Bug 1281536 - remove reader mode telemetry that's out of date, extend two existing probes, r=margaret,data-r=bsmedberg MozReview-Commit-ID: 2FSr4v4fPWU
577309fc4bbb328a7825b26818089c2af6c7bbf2: Bug 1282410 - part2 : open media with external apps. r=Margaret
Alastor Wu <alwu@mozilla.com> - Wed, 06 Jul 2016 10:53:53 +0800 - rev 384462
Push 22272 by bmo:lissyx+mozillians@lissyx.dyndns.org at Wed, 06 Jul 2016 10:08:23 +0000
Bug 1282410 - part2 : open media with external apps. r=Margaret MozReview-Commit-ID: KQDmOf2RURN
9e61b980ee9508abdecaed414b6a9ab55dc81985: Bug 1284017 - Add telemetry for damaged session store files. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 05 Jul 2016 22:40:01 +0200 - rev 384217
Push 22211 by mozilla@buttercookie.de at Tue, 05 Jul 2016 20:48:26 +0000
Bug 1284017 - Add telemetry for damaged session store files. r=margaret Just watching for a SessionRestoreException during startup can introduce some false positives, because that exception is triggered in any case where we can't restore tabs, not just when the session file has been damaged, e.g.: - on first startup - on builds affected by bug 1228593, users who are (theoretically) restoring their tabs, but clearing their history on exist end up with a deleted sessionstore.js - should we implement bug 1275662, we'd hit that exception in that case, too. Therefore we only send the telemetry event if we hit that exception even though a sessionstore.js file is present. We also exclude the case where the file size of sessionstore.js is 14 bytes, because that is most likely corresponding to a file containing only {"windows":[]}, which means that the session store intentionally wanted to write a file containing no tabs. Currently this is only the case for users who are clearing their history on exit and are also *not* restoring tabs, however if bug 1275662 should get implemented, we'd probably encounter those empty files for users who have their restore setting set to "Always restore", too. MozReview-Commit-ID: 6pAhDU3d8QA
276927d9031de1fb3175d6757813b2d05b15450c: Bug 1284017 - Add telemetry for damaged session store files. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 05 Jul 2016 22:40:01 +0200 - rev 384210
Push 22209 by mozilla@buttercookie.de at Tue, 05 Jul 2016 20:43:40 +0000
Bug 1284017 - Add telemetry for damaged session store files. r=margaret Just watching for SessionRestoreExceptions during startup can introduce some false positives, because that exception is triggered in any case where can't restore tabs, not just when the session file has been damaged, e.g.: - on first startup - on builds affected by bug 1228593, users who are (theoretically) restoring their tabs, but clearing their history on exist end up with a deleted sessionstore.js - should we implement bug 1275662, we'd hit that exception in that case, too. Therefore we only send the telemetry event if we hit that exception even though a sessionstore.js file is present. We also exclude the case where the file size of sessionstore.js is 14 bytes, because that corresponds most likely to a file containing only {"windows":[]}, which means that the session store intentionally wanted to write a file containing no tabs. Currently this is only the case for users who are clearing their history on exit and are also *not* restoring tabs, however if bug 1275662 should get implemented, we could encounter those empty files for users who *are* restoring their history, too. MozReview-Commit-ID: 6pAhDU3d8QA
7625ddbcf2a2dc6a3b7d1574975854c5a7cce5c0: Bug 1284013 - Part 2 - Reduce session store save delays when in background. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 17 Apr 2016 22:06:06 +0200 - rev 384185
Push 22196 by mozilla@buttercookie.de at Tue, 05 Jul 2016 19:20:51 +0000
Bug 1284013 - Part 2 - Reduce session store save delays when in background. r=margaret When we are backgrounded and Android's onPause() handler runs, we try to synchronously flush out any pending session store to storage. If however some tab events (e.g. tab closing) have been dispatched shortly before the application backgrounding, it is possible that they'll arrive at the session store after the "application-background" event. In this case, we need to process and write them to storage as fast as possible, as we can be killed at any moment now. Therefore the delay between successive writes is completely abolished while the application is in background. The minimum delay between a call to saveStateDelayed() and a write operation however is not completely eliminated and instead only reduced to 200 ms, so as to allow for closely following tab events (e.g. closing a tab involves both a TabSelect and TabClose event) to be batched together in one write operation. MozReview-Commit-ID: I8q7z4kll7O
55e9cfd7babc572d21a1e12a342dd914ee2e41d6: Bug 1284013 - Part 3 - Reduce session store save delays when in background. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 17 Apr 2016 22:06:06 +0200 - rev 384182
Push 22193 by mozilla@buttercookie.de at Tue, 05 Jul 2016 19:16:14 +0000
Bug 1284013 - Part 3 - Reduce session store save delays when in background. r=margaret When we are backgrounded and Android's onPause() handler runs, we try to synchronously flush out any pending session store to storage. If however some tab events (e.g. tab closing) have been dispatched shortly before the application backgrounding, it is possible that they'll arrive at the session store after the "application-background" event. In this case, we need to process and write them to storage as fast as possible, as we can be killed at any moment now. Therefore the delay between successive writes is completely abolished while the application is in background. The minimum delay between a call to saveStateDelayed() and a write operation however is not completely eliminated and instead only reduced to 200 ms, so as to allow for closely following tab events (e.g. closing a tab involves both a TabSelect and TabClose event) to be batched together in one write operation. MozReview-Commit-ID: I8q7z4kll7O
b79b44db1fbcb7edccc589308ad1d3b091e9b17e: Bug 1284013 - Part 2 - Defer writes if there's already an async write in progress. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 17 Apr 2016 21:41:32 +0200 - rev 384181
Push 22193 by mozilla@buttercookie.de at Tue, 05 Jul 2016 19:16:14 +0000
Bug 1284013 - Part 2 - Defer writes if there's already an async write in progress. r=margaret Currently, it is possible for a second write (sync or async) to be requested while a previous async write operation is still in progress. This might lead to undesired results if the second write is then completed before the first write, or if a sync write is interfering with a parallel async write operation. The only guard against a second async write is the minimum delay of 2 s between successive async writes enforced in saveStateDelayed(); there is no guard against sync writes. To avoid data loss when the application is backgrounded, it is desirable to reduce or completely eliminate this minimum delay (see Part 3), therefore we need to devise alternative means of ensuring that successive writes won't interfere with each other. With this patch, only one save operation is allowed to execute within _saveState() at the same time. Successive calls to _saveState() will be deferred, coalesced into one operation and executed once the previous async write returns from _writeFile()'s promise callback. Sync writes take priority, so if any of the deferred calls to _saveState() is a sync write, the resulting operation will be a sync write, too. This has the slight drawback that we can't execute truly synchronously within Android's onPause() call if an async state save is already in progress, however this should occur only very occasionally and is probably still more desirable than a possible write collision with a previous async state save. MozReview-Commit-ID: G2eogo1z8vr
7bb92418ebeeabd9abf45ea2e3e3a7f6c9a048a8: Bug 1284013 - Part 1 - Use temp file for synchronous writes, too. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 17 Apr 2016 18:22:36 +0200 - rev 384180
Push 22193 by mozilla@buttercookie.de at Tue, 05 Jul 2016 19:16:14 +0000
Bug 1284013 - Part 1 - Use temp file for synchronous writes, too. r=margaret Currently, sync writes go directly to the destination file, so an interrupted write will leave the session store data in an inconsistent state. To minimise the incidence of this occurring as far as possible, we now mimic the behaviour of atomicWrite when a tmpPath is set and write to a temporary file which is then renamed to the actual destination file after writing has finished. MozReview-Commit-ID: 3f3z1s0hfl8
23f23b76d914461389c7967b3ce959570b4320ae: Bug 1284013 - Part 0 - Fix session store logging logic. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 29 May 2016 16:52:49 +0200 - rev 384179
Push 22193 by mozilla@buttercookie.de at Tue, 05 Jul 2016 19:16:14 +0000
Bug 1284013 - Part 0 - Fix session store logging logic. r=margaret MozReview-Commit-ID: EGQzejCPNyS
78bf726daa84c0ac7e5d7912923d22184ee9bf5f: Bug 1282902 - Part 4 - Include zoom level recalculation in session store test. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 04 Jul 2016 22:12:34 +0200 - rev 384143
Push 22179 by mozilla@buttercookie.de at Tue, 05 Jul 2016 17:23:54 +0000
Bug 1282902 - Part 4 - Include zoom level recalculation in session store test. r=margaret Because we can't actually rotate the emulator within the test, we just manipulate the session store's stored display size to pretend that the device was rotated between tab data capturing and restoring. MozReview-Commit-ID: L2HzTLHcBQu
f0c70bfa8917bbb0ecd1939e40fa565377e203eb: Bug 1283582 - Stop displaying the context menu in Fennec if web content did a preventDefault on the event. r=margaret
Kartikaya Gupta <kgupta@mozilla.com> - Tue, 05 Jul 2016 10:09:38 -0400 - rev 384109
Push 22171 by bmo:npang@mozilla.com at Tue, 05 Jul 2016 15:57:20 +0000
Bug 1283582 - Stop displaying the context menu in Fennec if web content did a preventDefault on the event. r=margaret MozReview-Commit-ID: 4JQwXNfJxip
d41ee1432ba459c99df71c71af099d4ffb244728: Bug 1283582 - Stop displaying the context menu in Fennec if web content did a preventDefault on the event. r?margaret draft
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 30 Jun 2016 15:04:08 -0400 - rev 382881
Push 21860 by kgupta@mozilla.com at Thu, 30 Jun 2016 19:04:35 +0000
Bug 1283582 - Stop displaying the context menu in Fennec if web content did a preventDefault on the event. r?margaret MozReview-Commit-ID: 88PMQt2IiNs
7048a459dacf768c6dd093493f94930de5aab9f3: Bug 1279443 - Don't capture session state during startup before we've restored history. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 29 Jun 2016 18:24:13 +0200 - rev 382565
Push 21759 by mozilla@buttercookie.de at Wed, 29 Jun 2016 20:42:33 +0000
Bug 1279443 - Don't capture session state during startup before we've restored history. r=margaret When restoring tabs on startup, the Java UI creates tab stubs for the tabs from the previous session. The selected foreground tab then starts loading as soon as Gecko is up and running. Meanwhile, the session store gets initialised, too and starts restoring history and other things for that tab. After history has been restored for an active tab, the session store reloads the current history entry, however by that time, depending on device speed, page size and how many other tabs the session store has to process during startup, the initial page load might have progressed far enough to have already triggered various events monitored by the session store, e.g. "pageshow". If those events arrive before tab restoring has finished, the session store will attempt to capture that tab's state, which will overwrite the values stored from the previous session. Once the page is then reloaded for restoring, wrong values (e.g. form data, scroll position, zoom level) might then be restored. Therefore, we now abort any attempts to capture a tab's state - for all tabs until the "sessionstore-windows-restored" notification has been received as a signal that the initial session restore during startup has finished - for the restored foreground tab until the location change notification is received after reloading MozReview-Commit-ID: HbhXcEUnRXQ
08f50379cda7ee6d253f8b2eeb793898084fc8c8: Bug 1279443 - Don't capture session state during startup before we've restored history. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 29 Jun 2016 18:24:13 +0200 - rev 382563
Push 21757 by mozilla@buttercookie.de at Wed, 29 Jun 2016 20:40:29 +0000
Bug 1279443 - Don't capture session state during startup before we've restored history. r=margaret When restoring tabs on startup, the Java UI creates tab stubs for the tabs from the previous session. The selected foreground tab then starts loading as soon as Gecko is up and running. Meanwhile, the session store gets initialised, too and starts restoring history and other things for that tab. After history has been restored for an active tab, the session store reloads the current history entry, however by that time, depending on device speed, page size and how many other tabs the session store has to process during startup, the initial page load might have progressed far enough to have already triggered various events monitored by the session store, e.g. "pageshow". If those events arrive before tab restoring has finished, the session store will attempt to capture that tab's state, which will overwrite the values stored from the previous session. Once the page is then reloaded for restoring, wrong values (e.g. form data, scroll position, zoom level) might then be restored. Therefore, we now abort any attempts to capture a tab's state - for all tabs until the "sessionstore-windows-restored" notification has been received as a signal that the initial session restore during startup has finished - for the restored foreground tab until the location change notification is received after reloading MozReview-Commit-ID: HbhXcEUnRXQ
3734b79e5d0f0a69ced7c409c56842ae2e27c61d: Bug 1279443 - Don't capture session state during startup before we've restored history. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 29 Jun 2016 18:24:13 +0200 - rev 382562
Push 21756 by mozilla@buttercookie.de at Wed, 29 Jun 2016 20:36:45 +0000
Bug 1279443 - Don't capture session state during startup before we've restored history. r=margaret When restoring tabs on startup, the Java UI creates tab stubs for the tabs from the previous session. The selected foreground tab then starts loading as soon as Gecko is up and running. Meanwhile, the session store gets initialised, too and starts restoring history and other things for that tab. After history has been restored for an active tab, the session store reloads the current history entry, however by that time, depending on device speed, page size and how many other tabs the session store has to process during startup, the initial page load might have progressed far enough to have already triggered various events monitored by the session store, e.g. "pageshow". If those events arrive before tab restoring has finished, the session store will attempt to capture that tab's state, which will overwrite the values stored from the previous session. Once the page is then reloaded for restoring, wrong values (e.g. form data, scroll position, zoom level) might then be restored. Therefore, we now abort any attempts to capture a tab's state - for all tabs until the "sessionstore-windows-restored" notification has been received as a signal that the initial session restore during startup has finished - for the restored foreground tab until the location change notification is received after reloading MozReview-Commit-ID: HbhXcEUnRXQ
c83880885bcd7eaafd02de7ecbf57e849762c0d2: Bug 1282830 - Trigger session saves when closing zombie tabs, too. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 28 Jun 2016 23:29:57 +0200 - rev 382493
Push 21739 by mozilla@buttercookie.de at Wed, 29 Jun 2016 18:43:41 +0000
Bug 1282830 - Trigger session saves when closing zombie tabs, too. r=margaret A tab being in a delay-loaded "zombie" state or not shouldn't have any influence on the behaviour of onTabRemove - since we remove it from the session store's sphere of influence, its __SS_data can be safely deleted anyway and whether or not a session save needs to be triggered should depend only on the aNoNotfication parameter passed by the caller. Otherwise, with the current behaviour, the fact that those tabs have been closed will not get saved to disk if no subsequent session save is triggered through any other means (e.g. selecting a different tab, scrolling, ...) before closing Firefox. MozReview-Commit-ID: IxjZRRutc7A
2091f8c1a9405f56dfdc8a8b60e25a3dcf97a74a: Bug 1258549 - Upgrade fennec support links. r=margaret, a=sylvestre
Andrzej Hunt <ahunt@mozilla.com> - Fri, 03 Jun 2016 11:10:26 -0700 - rev 381697
Push 21529 by michael.l.comella@gmail.com at Mon, 27 Jun 2016 22:40:56 +0000
Bug 1258549 - Upgrade fennec support links. r=margaret, a=sylvestre MozReview-Commit-ID: 2fgrkbppx5g
5fa8da372343b0d92d10f8b06227ba2a86581aa7: Bug 1279306 - Use the production push server URL on Android. r=margaret a=gchang
Kit Cambridge <kcambridge@mozilla.com> - Thu, 09 Jun 2016 17:13:39 -0700 - rev 381679
Push 21529 by michael.l.comella@gmail.com at Mon, 27 Jun 2016 22:40:56 +0000
Bug 1279306 - Use the production push server URL on Android. r=margaret a=gchang MozReview-Commit-ID: Fy347g00Lx0
3c55e34b5259d9e656f93b18f2aebe46af09a732: Bug 1282423 - browser.js: Fix wrong open search expression. r=margaret
Sebastian Kaspari <s.kaspari@gmail.com> - Mon, 27 Jun 2016 15:33:35 +0200 - rev 381565
Push 21509 by felipc@gmail.com at Mon, 27 Jun 2016 19:25:05 +0000
Bug 1282423 - browser.js: Fix wrong open search expression. r=margaret MozReview-Commit-ID: KUXP4qcV7sM
119c6de712d426fa9c063e4a010c52a567f9b0cc: Bug 1282423 - browser.js: Fix wrong open search expression. r?margaret draft
Sebastian Kaspari <s.kaspari@gmail.com> - Mon, 27 Jun 2016 15:33:35 +0200 - rev 381483
Push 21488 by s.kaspari@gmail.com at Mon, 27 Jun 2016 13:34:20 +0000
Bug 1282423 - browser.js: Fix wrong open search expression. r?margaret MozReview-Commit-ID: KUXP4qcV7sM
7b73decd9ea17a12827ba239458ac1ffd10ba14b: Bug 1281536 - remove reader mode telemetry that's out of date, extend two existing probes, r?margaret,rweiss draft
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Fri, 24 Jun 2016 15:39:23 +0100 - rev 381194
Push 21419 by gijskruitbosch@gmail.com at Fri, 24 Jun 2016 16:58:03 +0000
Bug 1281536 - remove reader mode telemetry that's out of date, extend two existing probes, r?margaret,rweiss MozReview-Commit-ID: 2FSr4v4fPWU
55772f8675f35621f77d50a62d747aba71d7b069: Bug 1276910 - Do not show "Add to home screen" prompt in private browsing. r=margaret, a=sylvestre
Sebastian Kaspari <s.kaspari@gmail.com> - Mon, 06 Jun 2016 10:28:57 +0200 - rev 379565
Push 21011 by mak77@bonardo.net at Thu, 16 Jun 2016 13:40:45 +0000
Bug 1276910 - Do not show "Add to home screen" prompt in private browsing. r=margaret, a=sylvestre
be0703a058c65df02b8937f5b93417301f208688: Bug 1272340 - ToolbarDisplayLayout: Handle about:reader URLs. r=margaret, a=sledru
Sebastian Kaspari <s.kaspari@gmail.com> - Mon, 30 May 2016 14:29:53 +0200 - rev 379447
Push 21011 by mak77@bonardo.net at Thu, 16 Jun 2016 13:40:45 +0000
Bug 1272340 - ToolbarDisplayLayout: Handle about:reader URLs. r=margaret, a=sledru This patch changes two things: * Check if the URL is http/https after stripping the about:reader URL. * Always call updateAndColorTitleFromFullURL() as fallback for URL formatting (like in previous versions)
71b97e1011994fb5f1d60add58e3326e256d15a5: Bug 851969 - Add Amazon search suggestions to Android - r=margaret, a=sylvestre
Michael Kaply <mozilla@kaply.com> - Mon, 16 May 2016 10:47:34 -0500 - rev 379410
Push 21011 by mak77@bonardo.net at Thu, 16 Jun 2016 13:40:45 +0000
Bug 851969 - Add Amazon search suggestions to Android - r=margaret, a=sylvestre
fd75a1f393fe0173accbd1f14b14379b4266c503: Bug 1267935 - Remove NIGHTLY_BUILD condition from mobile theme. r=margaret, a=sledru
Ray Lin <ralin@mozilla.com> - Tue, 10 May 2016 22:50:01 +0800 - rev 379334
Push 21011 by mak77@bonardo.net at Thu, 16 Jun 2016 13:40:45 +0000
Bug 1267935 - Remove NIGHTLY_BUILD condition from mobile theme. r=margaret, a=sledru MozReview-Commit-ID: 6aEjc6meEtK
f0f690f287d8ee65c660ae30fcbaec710af6c58b: Bug 1271698 - Add Switchboard flags for URL bar changes. r=margaret a=ritu
Sebastian Kaspari <s.kaspari@gmail.com> - Mon, 16 May 2016 16:23:34 -0700 - rev 378881
Push 21011 by mak77@bonardo.net at Thu, 16 Jun 2016 13:40:45 +0000
Bug 1271698 - Add Switchboard flags for URL bar changes. r=margaret a=ritu * urlbar-show-origin-only: Only show origin in URL bar instead of full URL (Bug 1236431) * urlbar-show-ev-cert-owner: Show name of organization (EV cert) instead of full URL in URL bar (Bug 1249594)
7d1f3450acc47025876964c1eca854ae027934f3: Bug 1272166 - Update UI telemetry logging. r=margaret a=ritu FIREFOX_47_0b6_BUILD1 FIREFOX_47_0b6_RELEASE
Michael Comella <michael.l.comella@gmail.com> - Wed, 11 May 2016 17:30:34 -0700 - rev 378863
Push 21011 by mak77@bonardo.net at Thu, 16 Jun 2016 13:40:45 +0000
Bug 1272166 - Update UI telemetry logging. r=margaret a=ritu MozReview-Commit-ID: Gzb2qdm3TuT
3e9245c2bfaa9089cd3cc9e691159c091eb21e28: Bug 1268749 followup - Avoid querying :fullscreen selector for context menu. r=margaret a=ritu
Xidorn Quan <me@upsuper.org> - Fri, 13 May 2016 21:18:29 +1000 - rev 378821
Push 21011 by mak77@bonardo.net at Thu, 16 Jun 2016 13:40:45 +0000
Bug 1268749 followup - Avoid querying :fullscreen selector for context menu. r=margaret a=ritu MozReview-Commit-ID: A2Tn7I6h81Y
48e2f76e963f126c119917551fcc86332c68a784: Bug 1149859 - readermode now considers paragraphs with 100 chars acceptable instead of 200. r=margaret, a=readinglist GECKO380b1_2015040104_RELBRANCH
Mark Hammond <mhammond@skippinet.com.au> - Thu, 02 Apr 2015 14:58:48 +1100 - rev 378462
Push 21011 by mak77@bonardo.net at Thu, 16 Jun 2016 13:40:45 +0000
Bug 1149859 - readermode now considers paragraphs with 100 chars acceptable instead of 200. r=margaret, a=readinglist
6ab97a7c56eedb5298b8bab2e720a93d2186574e: Bug 1279306 - Use the production push server URL on Android. r=margaret
Kit Cambridge <kcambridge@mozilla.com> - Thu, 09 Jun 2016 17:13:39 -0700 - rev 377631
Push 20849 by dwillcoxon@mozilla.com at Sat, 11 Jun 2016 05:56:04 +0000
Bug 1279306 - Use the production push server URL on Android. r=margaret MozReview-Commit-ID: Fy347g00Lx0
b240666f8af8cd36887c3b312a41045ab8882f88: Bug 1227538 - Reset site identity after entering new URL. r=margaret
Sebastian Kaspari <s.kaspari@gmail.com> - Tue, 07 Jun 2016 16:54:13 +0200 - rev 377448
Push 20796 by gijskruitbosch@gmail.com at Fri, 10 Jun 2016 10:55:01 +0000
Bug 1227538 - Reset site identity after entering new URL. r=margaret MozReview-Commit-ID: oOPYDUPVq9
5596f971f169e94d0f38b09d35464d5254768d31: Bug 1279306 - Use the production push server URL on Android. r?margaret draft
Kit Cambridge <kcambridge@mozilla.com> - Thu, 09 Jun 2016 17:13:39 -0700 - rev 377305
Push 20784 by kcambridge@mozilla.com at Fri, 10 Jun 2016 00:17:48 +0000
Bug 1279306 - Use the production push server URL on Android. r?margaret MozReview-Commit-ID: Fy347g00Lx0
7f7f1ca1d0cd9c805679e9d196d85cc8f4687779: Bug 1190627 - Part 7 - Add telemetry probe for measuring how often we restore from the backup session copy. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 01 Jun 2016 22:04:59 +0200 - rev 377047
Push 20736 by mozilla@buttercookie.de at Thu, 09 Jun 2016 14:50:37 +0000
Bug 1190627 - Part 7 - Add telemetry probe for measuring how often we restore from the backup session copy. r=margaret MozReview-Commit-ID: JTR54Vk18jW
746ff120570c587228f937943385cfff78a92f12: Bug 1190627 - Part 6 - If an error occurs parsing the regular session store data file on startup, attempt to read the tabs from the backup copy instead. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 29 May 2016 15:46:20 +0200 - rev 377046
Push 20736 by mozilla@buttercookie.de at Thu, 09 Jun 2016 14:50:37 +0000
Bug 1190627 - Part 6 - If an error occurs parsing the regular session store data file on startup, attempt to read the tabs from the backup copy instead. r=margaret MozReview-Commit-ID: Kdh5d69irqF
530f688fd1b60cdb93cc9ad548aa35e336ac7977: Bug 1190627 - Part 5 - Do regular session data backups. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 29 May 2016 21:17:15 +0200 - rev 377045
Push 20736 by mozilla@buttercookie.de at Thu, 09 Jun 2016 14:50:37 +0000
Bug 1190627 - Part 5 - Do regular session data backups. r=margaret We now do a backup copy of the session store data at regular intervals to guard against interrupted write operations damaging the main session data file. We don't use writeAtomic()'s backupTo option, because that one works by first moving the old data to the backup file before attempting to write the new data, which might still leave us vulnerable against data loss if Firefox crashes or is otherwise forcibly terminated at precisely that moment. MozReview-Commit-ID: Cv52rmlfmfh
2619b6c36ced8250a2a136fe843e96bfbc57dbb7: Bug 1190627 - Part 4 - Reorganise session store file names. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 29 May 2016 13:25:43 +0200 - rev 377044
Push 20736 by mozilla@buttercookie.de at Thu, 09 Jun 2016 14:50:37 +0000
Bug 1190627 - Part 4 - Reorganise session store file names. r=margaret Currently, despite its name sessionstore.bak isn't actually a backup copy, but simply contains the last session if we aren't restoring tabs automatically and is used for powering the "Tabs from last time" section of the Recent Tabs panel. This patch changes its filename to sessionstore.old, which frees up sessionstore.bak to be used for an actual backup copy of the current session store data. If we are not restoring tabs automatically, sessionstore.old will be freshly recreated during each app startup by copying from sessionstore.js's contents, whereas if we *are* restoring automatically, any sessionstore.old file older than a day will be expired anyway, therefore no special migration logic is necessary for this change. MozReview-Commit-ID: H7Gl5MQi2J4
bcc5d94de1261b7bfb59e6d2eb50e30a6a73e54e: Bug 1190627 - Part 3 - Reduce session store save delays when in background. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 17 Apr 2016 22:06:06 +0200 - rev 377043
Push 20736 by mozilla@buttercookie.de at Thu, 09 Jun 2016 14:50:37 +0000
Bug 1190627 - Part 3 - Reduce session store save delays when in background. r=margaret When we are backgrounded and Android's onPause() handler runs, we try to synchronously flush out any pending session store to storage. If however some tab events (e.g. tab closing) have been dispatched shortly before the application backgrounding, it is possible that they'll arrive at the session store after the "application-background" event. In this case, we need to process and write them to storage as fast as possible, as we can be killed at any moment now. Therefore the delay between successive writes is completely abolished while the application is in background. The minimum delay between a call to saveStateDelayed() and a write operation however is not completely eliminated and instead only reduced to 200 ms, so as to allow for closely following tab events (e.g. closing a tab involves both a TabSelect and TabClose event) to be batched together in one write operation. MozReview-Commit-ID: I8q7z4kll7O
74bfa2a4752cd2f2ca0e96159502d372522d008d: Bug 1190627 - Part 2 - Defer writes if there's already an async write in progress. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 17 Apr 2016 21:41:32 +0200 - rev 377042
Push 20736 by mozilla@buttercookie.de at Thu, 09 Jun 2016 14:50:37 +0000
Bug 1190627 - Part 2 - Defer writes if there's already an async write in progress. r=margaret Currently, it is possible for a second write (sync or async) to be requested while a previous async write operation is still in progress. This might lead to undesired results if the second write is then completed before the first write, or if a sync write is interfering with a parallel async write operation. The only guard against a second async write is the minimum delay of 2 s between successive async writes enforced in saveStateDelayed(); there is no guard against sync writes. To avoid data loss when the application is backgrounded, it is desirable to reduce or completely eliminate this minimum delay (see Part 3), therefore we need to devise alternative means of ensuring that successive writes won't interfere with each other. With this patch, only one save operation is allowed to execute within _saveState() at the same time. Successive calls to _saveState() will be deferred, coalesced into one operation and executed once the previous async write returns from _writeFile()'s promise callback. Sync writes take priority, so if any of the deferred calls to _saveState() is a sync write, the resulting operation will be a sync write, too. This has the slight drawback that we can't execute truly synchronously within Android's onPause() call if an async state save is already in progress, however this should occur only very occasionally and is probably still more desirable than a possible write collision with a previous async state save. MozReview-Commit-ID: G2eogo1z8vr
699999a55d8697ac4f978209a21f24bcce6d1b79: Bug 1190627 - Part 1 - Use temp file for synchronous writes, too. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 17 Apr 2016 18:22:36 +0200 - rev 377041
Push 20736 by mozilla@buttercookie.de at Thu, 09 Jun 2016 14:50:37 +0000
Bug 1190627 - Part 1 - Use temp file for synchronous writes, too. r=margaret Currently, sync writes go directly to the destination file, so an interrupted write will leave the session store data in an inconsistent state. To minimise the incidence of this occurring as far as possible, we now mimic the behaviour of atomicWrite when a tmpPath is set and write to a temporary file which is then renamed to the actual destination file after writing has finished. MozReview-Commit-ID: 3f3z1s0hfl8
2dac3785f1406a65b4c239bcb2940dcb8aeca490: Bug 1190627 - Part 0 - Fix session store logging logic. r=margaret draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 29 May 2016 16:52:49 +0200 - rev 377040
Push 20736 by mozilla@buttercookie.de at Thu, 09 Jun 2016 14:50:37 +0000
Bug 1190627 - Part 0 - Fix session store logging logic. r=margaret MozReview-Commit-ID: EGQzejCPNyS
5753eb3ec41884030a12d9df006ee8fced481ca5: Bug 1278689 - Remove push subscriptions when clearing site settings on Android. r=margaret
Kit Cambridge <kcambridge@mozilla.com> - Tue, 07 Jun 2016 14:02:55 -0700 - rev 376742
Push 20653 by chevobbe.nicolas@gmail.com at Wed, 08 Jun 2016 15:36:47 +0000
Bug 1278689 - Remove push subscriptions when clearing site settings on Android. r=margaret MozReview-Commit-ID: BrOjKzswY1F
11880fa53889c4b79a2b6289958ee3b8031eb03f: Bug 1264057 - Don't show stale clients on the History Panel r=margaret
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 07 Jun 2016 14:48:16 -0700 - rev 376456
Push 20581 by cliu@mozilla.com at Tue, 07 Jun 2016 23:48:10 +0000
Bug 1264057 - Don't show stale clients on the History Panel r=margaret Currently we might have old (aka stale) clients appear on the History panel, which could be confusing. This patch modifies underlying query to select only those clients whose LAST_MODIFIED timestamp is newer than three weeks ago. MozReview-Commit-ID: JsZJwNONDJG
0f573f13be05b8d65f282eeb66c4746228ab6740: Bug 1278689 - Remove push subscriptions when clearing site settings on Android. r?margaret draft
Kit Cambridge <kcambridge@mozilla.com> - Tue, 07 Jun 2016 14:02:55 -0700 - rev 376386
Push 20561 by kcambridge@mozilla.com at Tue, 07 Jun 2016 21:04:04 +0000
Bug 1278689 - Remove push subscriptions when clearing site settings on Android. r?margaret MozReview-Commit-ID: BrOjKzswY1F