They're very similar as far as most users of the profiler are concerned, I'd
say, and I don't believe it's worth giving them two different colors in the
activity graphs.
MozReview-Commit-ID: HTqjp56naL3
--HG--
extra : rebase_source : cf8d64bc3e76ed9bb07100081aebfc404845b8bc
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : f807c14bf6a592e0c651e15b63d1e7d63e4b0159
This was used to label IndexedDB work and work in storage/mozStorage*.
I don't think this deserves its own category; categories are most useful for
the main thread, and most of the time-consuming database-related work happens
on helper threads. The main thread pieces are mostly for asynchronicity-
coordination and don't usually take up time.
This patch labels IndexedDB work as DOM instead (which is maybe debatable) and
the rest as OTHER.
MozReview-Commit-ID: 3UYhFFbi3Ry
--HG--
extra : rebase_source : f83946138d8311ea5aa91f537a1d8e420e784068
The next changeset is going to move over more annotations that Gecko developers
would count as "layout" into the LAYOUT category, and which is currently marked
as GRAPHICS.
We can add a subcategory for style resolution once we have subcategories, but
for now I think it makes more sense to put style resolution into the same bucket
as reflow and display list building.
MozReview-Commit-ID: 7r9eICVBA1Z
--HG--
extra : rebase_source : f447dcbb9d81be81a418c7464ef814ce4778073b
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : fb1ff20aeebb7ac494227e62ba2101039578808c
They're very similar as far as most users of the profiler are concerned, I'd
say, and I don't believe it's worth giving them two different colors in the
activity graphs.
MozReview-Commit-ID: HTqjp56naL3
--HG--
extra : rebase_source : ed1dc54efd143ad64bc21cfc39853ae90477cc9d
This was unintentionally removed in Bug 1265584.
MozReview-Commit-ID: 1t5Aq7OuI0x
--HG--
extra : rebase_source : fc8db167d0d3263bd66a68bfeef051d0574a115a
This commit is a (rebased) backout of changeset 016bcae14073 from bug 1322610,
which simply added a diagnostic to gather more information about a crash.
We can remove that diagnostic now, hence this commit.
MozReview-Commit-ID: 6ea7SAX4PSV
--HG--
extra : rebase_source : c13d9cd5bac4761cfe2dab51f67967462b1bd962
When the page navigates away, we should hide any active selection
actions.
MozReview-Commit-ID: 2LojAuPxyyl
--HG--
extra : rebase_source : 26240a67d036f313bece348a6b6106fd893fc853
Don't use a different thread when accessing the clipboard. The original
issue was using the clipboard required a thread with a Looper, when
GeckoThread did not have one. It does have one now so it's safe to
access the clipboard there.
Also, make hasText() return false for empty strings to avoid us
mistakenly think there is something on the clipboard.
MozReview-Commit-ID: AwKEcNnIkhT
--HG--
extra : rebase_source : 1af21efddcf461826a0da9b0407e27ee22d9cc31
Add UI thread checks and reformat some code in GeckoRuntime.
MozReview-Commit-ID: 2AE1IZGFnQd
--HG--
extra : rebase_source : 16650dec8bedf1988b136c09135ce6833b651c57
Use nsIDocShell.doCommand to perform selection actions, in order to
simplify code in GeckoViewSelectionActionContent.
MozReview-Commit-ID: IWVh7XfQ5l8
--HG--
extra : rebase_source : eed3862b1d3f6216fc02cb565626aa58a45c5a44
Add SelectionActionDelegateTest, which includes tests for all built-in
selection actions, for multiple content types such as input or
contentEditable.
MozReview-Commit-ID: Dzlzjo233Fe
--HG--
extra : rebase_source : 2d00bce24b1e7581d728994be8b63b40f6899003
Add support for using non-GeckoSession, external delegates with
GeckoSessionTestRule, so we can wait on the clipboard to change during a
test, for example.
MozReview-Commit-ID: D8sfJ8gMLaY
--HG--
extra : rebase_source : 7ff54c962fd1b8b0db78312558d3414ac29e3343
Add the "geckoview.selection_action.show_on_focus" pref for testing
only. The pref makes us show selection actions when the selection is
initially collapsed in an editor, which makes it easier to test behavior
for collapsed selections.
MozReview-Commit-ID: 3U6UfzokHaI
--HG--
extra : rebase_source : fa99dc24e50e09a905664e70ebc34b0ad219dfff
Currently, if the "layout.accessiblecaret.allow_script_change_updates"
pref is false, we always hide accessible carets when the selection
changes due to JS calls (e.g. setSelectionRange(0, 1)). If the pref is
true, instead, we update the accessible carets if they are already
visible. In either case, we never show the carets if they're invisible.
However for testing purposes, it's useful to make it so we do try to
show the carets if they're invisible. This patch replaces that pref with
the new integer pref "layout.accessiblecaret.script_change_update_mode",
which can be 0 or 1, which correspond to the old pref, or the value 2,
which introduces this new behavior of always showing the carets.
MozReview-Commit-ID: Bf1gPpIzcyb
--HG--
extra : rebase_source : 5eaba6c18d800da425d5e21f61af880678d7fe3c
Because of modifications to the DataTransfer constructors, the status of the tests that use DataTransfer objects had to be changed to reflect the fact that those tests now pass. Additionally, a test had to be deleted because it tested an obscure situation using the old Chrome only constructor.
MozReview-Commit-ID: LOWuPwh0NeW
--HG--
extra : rebase_source : bdfb4509b54925a27fb3fe7b83cb97ed4ea6d877
The changes made to echo-content.py are the same as the ones made in Bug
1435781.
MozReview-Commit-ID: GEPJxuptBii
--HG--
extra : rebase_source : 5ff06e70c52b2bf5666e2b79f11368dfe5a500fa
Deleted the old Chrome DataTransfer constructor because it was only used
for some tests which can be easily changed. Added a new constructor that
is not Chrome Only.
MozReview-Commit-ID: HjcgafSiWfM
--HG--
extra : rebase_source : 987afee2b6568bcf15c2ad99e715e6e0a112e3ed
Because we don't care about them for this build configuration.
MozReview-Commit-ID: JKEN2pN2x4K
--HG--
extra : rebase_source : b7ce0228f7086a5f933a7cdd6c4695eabb1530f1
Gtk checkboxes and radio buttons used to render a solid background on hover and so we also set a text color for that state. Apparently we're not getting that background anymore.
MozReview-Commit-ID: 7c5dbWroRbP
--HG--
extra : rebase_source : 4159ac0ff197f700e86692c7d1d939601c1453bd