DecodingState::Enter() will check whether decoding is completed and transition to COMPLETED.
MozReview-Commit-ID: 5abPWWulGWo
--HG--
extra : rebase_source : 75e70116c09819d6319c8d51c5685df2b46fea95
This avoids us trying to obtain an invalid cursor position, since
the cursor only maps to highlights items (and not the headers).
MozReview-Commit-ID: 1NtJuvDRa5r
--HG--
extra : rebase_source : e1034428d6f11221b3a58700b6250a215f64565e
This could still use a fair amount of additional cleanup.
MozReview-Commit-ID: BteBFMlZCsy
--HG--
extra : rebase_source : 8b37748c25cc5c871ebac3eaab34ae6780175f37
The `destroy` method in some actors would throw errors or was incomplete,
leading to various issues closing the toolbox after the previous patch.
This cleans up all such cases noticed through manual testing of the toolbox.
MozReview-Commit-ID: 6EZYFwjSri
--HG--
extra : rebase_source : b9db68be857285de4269f7354f6ecbf703c82e29
Ever since protocol.js was added as a way to create DevTools actors, we've had
lots of confusion about the correct way to implement actor destruction. If your
actor's _parent_ was the legacy kind, you had to use `disconnect`. If it was
protocol.js, you had to use `destroy`.
There is no reason for this madness, which makes reasoning about destruction
quite hard. Here we rename `disconnect` to `destroy` so there is only one name
for every destruction path.
MozReview-Commit-ID: C1Yw9NfUUR2
--HG--
extra : rebase_source : 4d018622b7547d404510e0b563c6324c0127aafc
Rewrite VsyncRefreshDriverTimer::GetTimerRate to always use the cached
value of the vsync rate in VsyncChild to avoid processing events on
the main thread.
Since VsyncChild::GetTimerRate is called in VsyncRefreshDriverTimer's
constructor, that cached value is bound to be set soon. This should
make the period of time we need to guess in
VsyncRefreshDriverTimer::GetTimerRate very short.
MozReview-Commit-ID: 1bnHNXAP8jY
--HG--
extra : rebase_source : 5a731962d417c4b3352970b2adb92b5d31de021c
Excessive clamping can cause incorrect behaviour in the presence of negative
margins.
MozReview-Commit-ID: AkQEqcQpAxx
--HG--
extra : rebase_source : 33cde31c15608792299a1dbef475e0fe0936270d
Based on an earlier patch by Nihanth Subramanya <nhnt11@gmail.com>
MozReview-Commit-ID: 4TZzFgovIJm
--HG--
extra : rebase_source : 0712c2145bf1c9e86b2c8a5eab0c240991b555e2
PluginContent listens for a particular type of Decoder Doctor notification.
Specifically, it listens for ones of type "cannot-play" for mimetypes that
include "application/x-mpegurl". If PluginContent sees that notification,
and we've already shown the Click-to-Play notification, then what we're
dealing with is web content that is probably using Flash to decode an
HLS feed. Because we don't want to spring up the Click-to-Play
PopupNotification on a Decoder Doctor notification (which might happen
at any time), we show the Hidden Plugin notification bar instead
to alert the user that they might need to enable Flash to view the
HLS feed.
MozReview-Commit-ID: IUFqhbhh0Sc
--HG--
extra : rebase_source : f88a51a6fbe3ffc4ce5ebb19903e9d0e97763976
This pref controls whether or not the platform looks for and trusts enterprise
roots (currently only available on Windows). Adding it to security-prefs.js will
make it appear in about:config, which is a much more straightforward user
experience (previously users would have to add it manually). It is still
disabled by default.
MozReview-Commit-ID: 6pQkh2gTNTF
--HG--
extra : rebase_source : 5479492f3a9f802d1fc02c6d3fdc3d54c81f8fe9
instead of using the context belonging to a widget.
Only the style context is cached, instead of the whole widget.
Using the style context from a widget meant that rendering displayed the
initial appearance of animations after state changes, but there was no
invalidation to trigger the final rendering in the animations.
Style contexts constructed from paths do not incorporate animations.
(See gtk_css_path_node_update_style() in GTK.) Therefore they provide the
appropriate rendering for Gecko's model, which is not expecting animations.
There is no mechanism available to display animations when using style
contexts constructed from paths, but the GtkWidget animation design is also
not suitable for rendering potentially multiple elements each in a different
state of their animation.
This contexts-from-paths approach can be extended also to other widget types,
but this is a smaller change intended for uplift to other branches to address
a regression in menuitem rendering.
MozReview-Commit-ID: EFV7swWQtm4
--HG--
extra : rebase_source : 689f7340007c889ce0eaeb3b4acd228d45ad0d6d
