- specifying states, events and transition side-effects explicitely makes this code easier to read/maintain
- move bunch of network state helper methods into NetworkUtils
- ensure to update both network state (up/down/unknown), as well as connection type/subtype every time we need to update network state
-- this should fix the buggy behaviour when we'd miss certain network state transitions
- tests for the FSM transition matrix, and everything in the NetworkUtils
MozReview-Commit-ID: LvrfHyFdkpB
--HG--
extra : rebase_source : 4429d80f78435205915f27e738e4886f1c46d3fa
Opening/navigating within/restoring a tab seems to be relatively slow on the emulator and as we want to test whether form data is preserved by the session store after closing and restoring a tab, quite a bit of time is accumulated that way.
MozReview-Commit-ID: 3LhLuZIZ2z7
--HG--
extra : transplant_source : %C7%22%90%DFy%97%BCD%B3%17%FE%F0%09%7FQ6V%D4%0E%1B
userTypedClear was used for two cases:
1) to keep track of whether we were in the middle of a loadURI call. This use is replaced by inLoadURI, which is
more sane when using e10s (though it's hard to be precise there because we're sending all web navigation calls to
the content process and this introduces a degree of asynchronousness that we just have to live with...).
2) to keep track of whether we were between a network start and a corresponding network stop, and whether the user
typed since the load properly started. This is now tracked on a small object on the browser binding, which has
appropriately named method so we're not just incrementing some magic number but actually understand what
we're saying, and so the information we get out (did the user type since this load started or not?) makes sense.
Note that we're keeping userTypedClear in session store information in order to remain backwards compatible.
It becomes a simple boolean-stored-as-int (1 or 0) that indicates whether we quit/crashed/stopped while a load
was pending, or not.
MozReview-Commit-ID: 5NbmVueocC7
--HG--
extra : rebase_source : f87199c77094c24c132e6c88f751a5b5d5aa62f9
During shutdown, mozilla::services::GetObserverServie will return nullptr. So we should check it. Add another nullptr check
MozReview-Commit-ID: 9xBbltRatJF
--HG--
extra : rebase_source : a859de09f30eeba344c317aec4cf4ed2cce8da2b
extra : histedit_source : 325aba902eff367d046807e9be3a73ad3100ee67
I'm acting under the assumption that this is what's closest to what the
code does now, except without asserting in ~ErrorResult. It also seems
closest to what event listeners will do, both based on examining code
(EventListenerManager::HandleEventSubType, which I'm hoping is the right
code to look at, calls StealNSResult, and then stores it in a member
that's ignored by most callers) and based on testing (for both click
events, and for media query listeners with this patch, the exception
gets reported to the console as an unhandled exception). That said, I'm
not particularly well versed in the current error handling rules so I
may well be off here.
This code should presumably go away when we change this code to use
EventListeners in bug 1265622, so I don't think there's any spec that
covers this.
Without the patch, the mochitest hits the fatal assertion (after
reporting hitting the expected uncaught exception). With the
patch the test passes. (Tested locally.)
MozReview-Commit-ID: 5kxp6jzGzX8
--HG--
extra : transplant_source : n%B4%AE%99D%FB%B9NM%C0%A2%F0%D4%B7%8C%E7%DE4E%60
When tab with a userContextId!=0 contains a chrome page (such as
about:newtab) the userContextId in the LoadInfo won't match the
userContextId in the LoadContext. The LoadInfo will contain the
systemPrincipal and so use userContextId=0, the LoadContext has the
userContextId of the tab (!=0).
This is fine as long as we page only loads chrome-URLs and other
non-http URLs since those don't use cookies anyway.
So avoid asserting in this situation.
Long term we want the chrome page to use the default userContextId for
cookies, since that's what it chrome code normally use. This will work
properly once we get the cookie jar information from the LoadInfo rather
than from the LoadContext.