This is only done by the Return-to-AMO flow, which is not supported in MSIX anyways.
Also, disable the RTAMO test for MSIX builds while we're here.
Differential Revision: https://phabricator.services.mozilla.com/D164666
Previously we were checing if there is a profiling directory to decide that
it's an extra profiler run. But actually this is incorrect because it can still
be an extra profiler run with a failed output. So we skip checking that
directory while deciding if it's a profiler run, and add an additional check to
see if this step is failed.
Differential Revision: https://phabricator.services.mozilla.com/D164662
This has some provision to continue working if the tab is closed or reloaded,
but it's not fool proof. Eventually we might want to move this to a service, but
it's already very useful as it is.
Differential Revision: https://phabricator.services.mozilla.com/D160213
FOG gets to learn which app ids register which pings, allowing it to tell the
Glean SDK to trim all data not associated with those pings.
This will keep other app_ids' custom pings' events from growing without bound.
Alas, this does not come with tests as the trim behaviour is very internal to
the SDK. As such we'll have to rely on the SDK's tests.
Depends on D164604
Differential Revision: https://phabricator.services.mozilla.com/D164605
`.footer` is no longer used on extraClasses, so I got rid of that.
I simplified the `.entry` bits because they were unnecessarily
verbose. Honestly I think we may be able to remove the getter/setter
for `options` entirely, but I got bored of trying to modernize things...
PlacesPanelMenuView was introduced in bug 963095 and then replaced
as part of Photon (with PlacesPanelview) and then I removed the only
callsite (that was already behind a pref) in bug 1354117, so that was
just dead code, AFAICT, so I removed it.
Differential Revision: https://phabricator.services.mozilla.com/D164757
Only the bookmarks menu button is doing this peculiar re-using of
options.
I tried various fixes: keeping the inheritance but replacing only the
rootElt/viewElt (and using Object.assign to clone the options so modifications
don't 'transmit' to the ancestor menus) but it was messy and net code increase
for a pretty crufty UI surface. I also wasn't sure if that would end up
negatively influencing (now or in the future) e.g. menus shown from the main
bookmarks toolbar view (which would show up as a 'parent' view for the menus
we open from there), and thought that reusing the options was likely to cause
further confusion in future as well, should we add more, uh, options, to them.
So in the end I stuck with Keeping It Simple - I just repeat the one-off
repeating entry class. I'm not even sure how needed this is - in particular,
I wonder why we don't need it for other submenus for 'real' bookmark folders!
But I didn't investigate this too much. If you're sure that we can get rid of
some more of it, happy to do that in a followup.
Note that the addition of _init() was not ultimmately needed to fix this bug
(I think), but it brought the initialization sequence and when we set
`_placesView` more in line with what we did before and what I already did for
`PlacesToolbar`, so that seemed like a good thing to avoid further/other issues.
Differential Revision: https://phabricator.services.mozilla.com/D164756
gst-launch-1.0 appears to be blocking while the pipeline is running, and this
is different from previous versions. This patch makes us spin up a separate
process for gst-launch before starting tests, and makes sure it is killed
as the mochitest runner shuts down.
Differential Revision: https://phabricator.services.mozilla.com/D163824
To help test parallel marking this patch enables it in some browser TSAN tests.
This change will be removed when it is enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D164579
Chrome preserves inline styles of first character in the deleting/replacing
if first visible thing is text. Safari preserves inline style of the first
content of the range (i.e., styles of `<img>` etc is also respected).
For now, due to the market share and Safari's behavior is not obviously better
than Chrome, let's try to emulate the Chrome's behavior. However, the rules are
complicated and probably depend on how it implements the deletion. Therefore,
this patch makes Gecko only scan following text node if selection range starts
from end of a text node.
Depends on D164520
Differential Revision: https://phabricator.services.mozilla.com/D164521
Currently, `HTMLEditor` preserves styled elements with the reversed order in
the loop.
https://searchfox.org/mozilla-central/rev/d7d5c89ee7bc70dec0fd846689ca030f94931393/editor/libeditor/HTMLEditSubActionHandler.cpp#8638-8658
I.e., if `<b><i></i></b>` is restored in the HTML styling mode, it will be
restored as `<i><b>...</b></i>`. This blocks writing tests for bug 1789574.
Therefore, this should be fixed first.
(As I commented in the method, ideally we should store all inline elements and
restore all of them, but currently we don't need to do it. It requires redesign
of the style cache, but it seems that we don't know web apps which is broken by
current behavior. Therefore, I think that we should do it when we meet a
trouble with the behavior.)
Depends on D164519
Differential Revision: https://phabricator.services.mozilla.com/D164520
This patch removes some traditional behavior check in the mochitest and
port it into expected results which match with the behavior of Chrome.
Almost all the new tests pass in Chrome, but some fails due to odd result in
Chrome. E.g., Chrome sometimes append `style` attribute with empty value.
Therefore, the expectations in this patch must be what Chrome developers
expected at implementing it.
Depends on D164004
Differential Revision: https://phabricator.services.mozilla.com/D164519
Logs engagement telemetry for debug purposes, regardless of it being reported
upstream.
Also changes a couple other logs to make browser.urlbar.logLevel = "Info"
more readable and usable.
Differential Revision: https://phabricator.services.mozilla.com/D164701
