I expect the crashes occurred because one of the following:
* the store already existed as a file
* the store was a directory that did not have the appropriate permissions
In the telemetry code, none of the cases above should happen so I assert that
they never do.
If the crashes did occur for these reasons, the user will unfortunately
continue to crash but at least we'll know where our assumptions are going wrong.
I originally intended to write a regression test for listFiles returning null
but it requires the application code to be modified in non-trivial ways (e.g.
accessor methods we might forget to use) so I decided against it.
MozReview-Commit-ID: 9V9H84ehbdO
--HG--
extra : rebase_source : 8290e515c9010bef639e92d1b0420bebe5c7d61c
This changeset will correct the crash we're seeing in the bug.
The docs support that File.listFiles can return null.
MozReview-Commit-ID: FHYGErshhoP
--HG--
extra : rebase_source : 15d0c4a3d283924627f1f97a1f99637244c49c08
This will be used to enable the activity stream panel in place of the HomePager. We are
likely to migrate this to a switchboard flag in future once the new panel becomes
shippable (we are still investigating other distribution mechanisms, so it is entirely
possible this will completely change in future).
MozReview-Commit-ID: I9VSliO0IXE
--HG--
extra : rebase_source : 5c6578e41d7bc4849a7aa4a74c4be6cebc966231
This will permit us to plug in other HomeScreen implementations as needed.
MozReview-Commit-ID: Dvmyk1sdBT6
--HG--
extra : rebase_source : bf8acdf84e35f9b2dbeaa2445121c1cfa6d974e4
This is to help keep the terminology more clear: this container will allow displaying any of our
home screen implementations, and not just the HomePager.
MozReview-Commit-ID: 4kqNipgvQ5I
--HG--
extra : rebase_source : 831090edf10be23baf358d778934e73534b720f2
GET_SERVICES is already implicit in this method name. Using lint running against
sdk 24 we get a warning that GET_SERVICES isn't a permitted flag. (Previous sdks
didn't yet contain a list of allowable flags.)
MozReview-Commit-ID: LINassWOTfc
--HG--
extra : rebase_source : f3e654849fff8a1bd0e10566e5382991d47cefb4
extra : histedit_source : 1c3545c90e4351147fe2da072814c2c6b53f19d9
We're still building with the 23 sdk, but lint is now giving us errors based
on the 24 sdk. We therefore need to explicitly suppress the error (even though
in reality we don't want to suppress the error so that we don't miss adding the
@Override annotation when we switch to 24).
MozReview-Commit-ID: 3RqLMhiyAFh
--HG--
extra : rebase_source : 0d298d5f1245286f5946d544422b87e6a51c04ed
extra : histedit_source : 3e5e2dfb28cf9a55c006803a8df68a7942381a54
We want to be able to detect when we've opened a reader view item. Note: this is
independent of whether or not we're in the Reading List smartfolder: it's possible
to open reader view bookmarks from any real bookmark folder, or the smartfolder.
MozReview-Commit-ID: KhqclodWSji
--HG--
extra : amend_source : 96460a430de900920dc2858dc171544657771abb
That way, the section headers (e.g. "Today", "Yesterday", "Last 7 days" etc.) blend better with the following item.
The correct hiding of the divider depends on the view type reported for the respective RecylerView child items. Because the view type is stored a simple number, this means that any other RecylerView wanting to use this divider decoration implementation must use the same item types as the history panel in order to remain compatible, otherwise the divider could be unexpectedly hidden. Therefore, we rename the DividerItemDecoration to underline its intended usage scope.
MozReview-Commit-ID: 8JUS6ke3RBL
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/widget/DividerItemDecoration.java => mobile/android/base/java/org/mozilla/gecko/widget/HistoryDividerItemDecoration.java
extra : transplant_source : %E8%B7%8E%9F%C9%E5%CCmX%22r%D7%D2%8A%DF%2A%D0%83%9Bw
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.
Because of bug 1261008, we can also end up with no restored tabs (and a SessionRestoreException) if the session file contains only about:home tabs with no history, because we're skipping those and not restoring them. To detect that case and exclude it from telemetry, we have to include additional logic within the SessionParser instance used during startup and pass those results back to the calling site in GeckoApp.
MozReview-Commit-ID: 6pAhDU3d8QA
--HG--
extra : rebase_source : ebf4d902a616c17ba10c645ad8ef469ceafe8cce
Michael Comella
Andrzej Hunt
Carsten "Tomcat" Book
Makoto Kato
Geoff Lankow
Sebastian Kaspari
Geoff Brown
Thomas Wisniewski
Alastor Wu
Michael Kaply
Tom Klein
Jan Henning
Kris Maglione
Matthew Wein
Nicholas Rosbrook
Wes Kocher
Mike Taylor