In bug 1147911, the concept of a remoteType was added to a xul:browser.
This was an attribute which would control the type of remote process was
intended to be used to load the page.
In order to swap two frameLoaders, it has always been necessary for them
to either both contain remote content, or both contain non-remote
content. This check is made in nsFrameLoader::SwapWithOtherLoader, by
checking `IsRemoteFrame() != aOther->IsRemoteFrame()`, and then
returning `NS_ERROR_NOT_IMPLEMENTED` if that was not the case.
In the follow-up bug 1317293, the check which is being removed here was
added to ensure that the remoteType of two frameLoaders which are being
swapped also matched. This was not a technical limitation, but rather
something which "seemed to make sense to do".
This bug removes that check as it is not a technical limitation and
causes problems in edge cases around Large-Allocation processes now that
the remoteType is being used to denote a Large-Allocation process.
Namely, it means that attempting to drag a Large-Allocation window into
a new window when at the Large-Allocation process cap will fail, due to
being unable to create a new Large-Allocation process in the new window
to swap with.
The new swapping of the attributes which is added below is done with the
intent that the `remoteType` attribute of the xul:browser element should
match the `remoteType` attribute of the frameLoader inside of it at all
times. As the swap can now occur between two different `remoteType`s,
this is necessary to keep that constraint.
MozReview-Commit-ID: BHFgjwRGrge
By default RecyclerView assumes any item change *might* need animation. It then
creates a new copy of the item that has changed, and interpolates between the two
to "animate" the change. We don't need that for topsites (the RecyclerView's we use
inside each TopSitePanel already animate changes, the overall size doesn't change -
moreover ViewPager state gets lost if you create a new panel), so we override
this behaviour to retain the existing panel. This stops the previously visible
horrible flickering.
(Every time history changes, which can happen if sync is working, or even if a page
finishes loading in the background, the DB is changed, and a reload is triggered.
Prior to this commit, topsites would flicker horribly, and would reset back to the first
topsites page. After this commit the page is retained, and the visible topsites
are rearranged by the inner RecyclerView's animations. You can test this by pinning a
site on the first page, the pinned site will shift to the front, the other sites smoothly
move to the right.)
MozReview-Commit-ID: CnocNfdQ2FS
--HG--
extra : rebase_source : 3a4e1d86c786126aee1e08ab020b855056e4f921
If we clear and recreate pages every time the cursor changes, we'll (A) lose
the current page position and (B) create a new RecyclerView per page, resulting
in flickering. We also need to make sure positioning is correctly handled (i.e. pages
never move, they only get added or removed).
We also switch to an ArrayList: the number of pages will be fixed for most users,
and searching an ArrayList could potentially be slightly faster than with the LinkedList.
There's little advantage to a LinkedList here.
MozReview-Commit-ID: 6NIfc2otQMV
--HG--
extra : rebase_source : 86b51be92c18e791f8049b5c90441370c6bace9a
This fixes a trivial mistake in #15533, caused by me misreading the spec. r? @Manishearth
Source-Repo: https://github.com/servo/servo
Source-Revision: 3fa9ce16db910c0b44617dafdcd8e76b6f813c61
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 668d521e0ecc9c92b9d5f7af48d72eeffc490815
Changed |print("enum ID : uint32_t {", file=output)| to |print("enum HistogramID : uint32_t {", file=output)| at line 53 of the file |toolkit/components/telemetry/gen-histogram-enum.py|, and then replaced all the textual occurrences of |Telemetry::ID| to |Telemetry::HistogramID| and |ID| to |HistogramID| in 43 other files.
