Doing std::move when returning/assigning a local or temporary object is
preventing the compiler from performing copy elision.
Differential Revision: https://phabricator.services.mozilla.com/D5019
--HG--
extra : moz-landing-system : lando
This patch introduces some options that can be passed to
setItems and openPopup to prevent doing unecessary work.
The main ideas here are to create all the popup items and
put them in a document fragment which then will be appended
to the popup, so we don't add them one by one which can be costly.
When creatingthe items, we also create one directly with the
selected class if autoSelect is set to true. This way, we don't have
to toggle the class later (which led to another reflow).
We take this work as an opportinuity to clean up the component.
Unused function (like appendItem and removeItem) are removed,
selectedIndex does not use a getter/setter anymore.
Some of the consumers calls are updated and so is the component test.
Differential Revision: https://phabricator.services.mozilla.com/D4848
--HG--
extra : moz-landing-system : lando
HTMLEditor::HideResizers() is an XPCOM method, so, we should create non-virtual
method for internal use.
Differential Revision: https://phabricator.services.mozilla.com/D4923
--HG--
extra : moz-landing-system : lando
All classes deriving from nsIFrame that did not have any subclasses themselves
(at the time of writing this patch) have been marked with `final`.
Some other Layout classes have also been made final, but this was opportunistic
while working on nsIFrame subclasses, and is definitely not exhaustive, further
patches welcome; refer to bug 1332680.
Advantages of marking a class final include:
- Allowing the compiler to devirtualize some method calls (i.e., calling
virtual functions directly instead of going through the vtable),
- Indicating that the class is not currently subclassed,
- Preventing subclassing without being aware that this would remove the
finalization benefits of the parent class.
`final` does not signify that these classes should *never* be subclassed, this
is left for developers to decide.
Differential Revision: https://phabricator.services.mozilla.com/D5020
--HG--
extra : moz-landing-system : lando
As described in c2b5cf7bde83, it is still preferable to build with BFD
ld when doing clang LTO, and one of the reasons we defaulted to lld in
the first place is that we didn't have the LLVM gold plugin on
automation, which, as of bug 1488307, we now have.
Differential Revision: https://phabricator.services.mozilla.com/D4987
The browser_all_files_referenced.js test partly relies on finding chrome
and resource urls in the libxul binary, but with LTO, clang actually
replaces AssignASCII calls to inline copies using immediate values, like
this:
movabsq $0x726573776f72622f, %rcx
movq %rcx, 0x8(%rax)
movabsq $0x2f3a656d6f726863, %rcx
movq %rcx, (%rax)
Those immediate values are, respectively, "/browser" and "chrome:/".
Somehow, the aboutNetError-new url is the only one where that causes
problems, which is kind of surprising, in a sense. It's also in a
special position, being temporary until aboutNetError is actually
replaced and the new about:certerror rides the train. Chances are, if we
add an exception for aboutNetError-new in the
browser_all_files_referenced.js test itself, it would remain there after
the new about:certerror rides the train.
However, using the somehow circumvoluted Assign(NS_LITERAL_CSTRING())
construct, we can prevent clang from LTOing the string into pieces. And
there are better chances the code will go away when the new
about:certerror rides the train.
Differential Revision: https://phabricator.services.mozilla.com/D5017
Bug 1464036 changed how JSID_EMPTY was defined; this patch updates the gdb
plugin accordingly.
Depends on D4611
Differential Revision: https://phabricator.services.mozilla.com/D4612
--HG--
extra : moz-landing-system : lando
This accounts for internal hash table changes in bug 1478896 and bug 1462261.
Depends on D4610
Differential Revision: https://phabricator.services.mozilla.com/D4611
--HG--
extra : moz-landing-system : lando
This accounts for changes to the layout of JS::Value from bug 1449051.
Depends on D4608
Differential Revision: https://phabricator.services.mozilla.com/D4609
--HG--
extra : moz-landing-system : lando
This updates the pretty-printer for JSStrings to account for the internal
changes in bug 1479900.
Depends on D4607
Differential Revision: https://phabricator.services.mozilla.com/D4608
--HG--
extra : moz-landing-system : lando
This patch contains a set of changes needed to add WEBEXT telemetry probes keyed by addon id.
The telemetry probes keyed by addon id has been added as separate telemetry histograms
named after the related generic WEBEXT probe with the additional "_BY_ADDONID" suffix.
A set of small helper methods have been defined in a new ExtensionTelemetry object, exported
by the ExtensionUtils.jsm.
Differential Revision: https://phabricator.services.mozilla.com/D4437
--HG--
extra : moz-landing-system : lando
This has two parts:
(1) urlbar already had a formatValue method. Right now, it only does the URL formatting (domain highlighting, crossing out https for mixed content pages) that we do when the urlbar is not focused. This patch generalizes that method into a kind of "any formatting you want to do, do it here" method, and it adds alias formatting.
formatValue is called by the base autocomplete binding when `value` is set. So it's called when the selection in the popup changes and the autocomplete controller subsequently sets the input value. (It's also called by urlbar on focus and blur.) And if anyone else sets the value directly, it'll be called then too of course.
But it's not called when you're just typing in the input, so I added a call in urlbar.onResultsAdded, where we were calling highlightSearchAlias, to handle the first heuristic result being added or modified as a result of what you type.
So I think that should cover all possible times we need to highlight the alias?
(2) Just looking at the selected result to get the alias in the input doesn't work all the time. If you click a search tile on newtab and then key around in the popup, sometimes when you key down to the one-off buttons, the input value reverts to the alias (it's the user-typed value I guess?), but at the time that the value setter is called during the revert, the popup's selected index is still the last selection in the popup. IOW the selected index doesn't match up with what's in the input.
Rather than deal with that, it seems safer to call PlacesSearchAutocompleteProvider.findMatchByAlias() on the first word in the input. But that has a couple of problems. It's async, and I noticed there can be a slight delay in the highlighting appearing. Also, we've already gotten the information returned by that method, when we generated the results in the first place, so it seems inelegant to call it again.
So what I've done instead is to cache aliases in the popup when results are added, and then just look up the first word in the input in these aliases. We shouldn't reset this cache until the first result of a new search comes in.
Differential Revision: https://phabricator.services.mozilla.com/D3850
--HG--
extra : moz-landing-system : lando
As of bug 1346297, we don't collect telemetry for the family safety root
feature. At this point, it makes the most sense to disable the entire feature by
default.
Differential Revision: https://phabricator.services.mozilla.com/D4994
--HG--
extra : moz-landing-system : lando
I'd claim that we don't need it because, in order to enqueue the event, we
already need to have overflowed the event in a normal reflow.
For now this should not break anything (or anything that wasn't already racy
depending on when we paint).
The only reason the flush is there is according to roc is to decide whether to
fire the event, and because it needs the layout information:
https://bugzilla.mozilla.org/show_bug.cgi?id=771822#c4
In practice, however, all the layout information we need we have already
computed by the time we post the event.
We don't expose the rects via the event details, which is what could get
out-of-date, so this patch could only mean that we fire the event slightly more
often in cases where people remove stuff from the DOM, right after we do layout
and the content has overflowed. But that's actually pretty unlikely.
This event in general is pretty problematic because it exposes when we do
layout and when we paint, which is not great. Its test coverage is also pretty
low (test_overflow_event.html, which of course still passes without this).
I still want to do this change first since it's trivial to back out if needed.
Then I'd want to change how it fires to match the scrolled area change event
(which would allow us to remove the WillPaintObserver stuff), after verifying
that chrome consumers are still fine with that, and then put behind a pref and
hide it from content, while we leave time for chrome consumers to migrate away
from it, and allow us to revert if something breaks.
Differential Revision: https://phabricator.services.mozilla.com/D5082
--HG--
extra : moz-landing-system : lando
- Make crash submission explicit by triggering it via a button instead of by
clicking on the crash ID link.
- Replace the single "Remove All Reports" button with two "Clear All" buttons,
one for each category of crashes.
- Add a "View" button instead of making crash IDs links to make it explicit that
you are viewing crash data and not submitting it.
Remove implicit dependence of the order of crash IDs in about:crashes test.
Differential Revision: https://phabricator.services.mozilla.com/D4728
--HG--
extra : moz-landing-system : lando
As of bug 1346297, we don't collect telemetry for the family safety root
feature. At this point, it makes the most sense to disable the entire feature by
default.
Differential Revision: https://phabricator.services.mozilla.com/D4994
--HG--
extra : moz-landing-system : lando
Loading enterprise roots could potentially take a while, so we certainly
shouldn't do it on the main thread at startup. Note that this doesn't address
the case where a user enables the feature while Firefox is running. This isn't
great but since it's an about:config preference rather than a first-class
preference exposed in about:preferences, we can probably get away with it for
now.
Differential Revision: https://phabricator.services.mozilla.com/D4708
--HG--
extra : moz-landing-system : lando
Also remove a useless line that looks like some debugging code I accidentally left in.
Differential Revision: https://phabricator.services.mozilla.com/D5059
--HG--
extra : moz-landing-system : lando
