TSFTextStore::sEnabledTextStore is a static variable to grab a reference to focused TextStore instance. So, this may be changed by accidentally during a call of instance methods of TSFTextStore. Then, focused TextStore may be destroyed during running a method and crash when it accesses a member variable.
For avoiding this crash, static methods which call a method of sEnabledTextStore should create an independent RefPtr to it before calling the method.
MozReview-Commit-ID: 51Sor1LdABr
The clamping already happens on the content side, in nsLayoutUtils::GetDisplayPort
and friends. The clamping there is more accurate as it reflects the latest main-
thread information about the size of the page and position of the displayport
base rect, which the compositor thread does not have.
Since we are not clamping the displayport on the compositor side, it can "slosh
around" a bit more and ends up sending a few more repaint requests when scrolling
near the edges of the scrollable frame. This causes some gtests to fail because
of the "extra" repaint requests. Disabling the velocity bias removes the
sloshing around and fixes the test failures.
MozReview-Commit-ID: JgBDi0M3Wtt
The Adobe GMP unencrypted decoder can't decode unencrypted input which has
valid crypto data attached; it thinks the sample is encrypted, and returns a
crypto error and decoding fails. The sample should be decrypted by the time
we pass it to the wrapped decoder, so decoding should succeed without the
crypto data.
MozReview-Commit-ID: KjZcQyYiRqp
nsContentIterator isn't designed as working fine with a tree whose some nodes are being removed. In such case, NextNode() and PrevNode() meets orphan node (i.e., a node whose parent is nullptr). Then, nsContentIterator should mark it as "done".
However, it should keep crashing if it's debug build for detecting bugs explicitly.
MozReview-Commit-ID: 81ZQgoHD67T
The session store relies on a few event listeners to track the history and life cycle of a tab. Under memory pressure, background tabs are zombified in order to reduce our memory usage. This involves destroying the original tab object and then recreating it as a delay loaded tab.
As the session store is never told about this, it will keep the event listeners for the old tab objects - which have now been destroyed - alive and won't receive any future events for the new tab objects. This means that once a zombification has been triggered, the session history for those tabs will become effectively frozen, so after the next zombification or a session restore, the tab will reload the wrong page.
Therefore this patch introduces two new events which are sent during the tab zombification process and allow the session store to detach its event listeners from the old tab object before it is going to be destroyed and subsequently reattach its listeners to the new tab object.
MozReview-Commit-ID: 6xZtsCNZbQY
