Also detect existing users and carry forward their customizations if needed.
If no customization was done, we set a pref to indicate they should remain
at their old defaults, which we can gradually migrate to the new values.
Differential Revision: https://phabricator.services.mozilla.com/D88162
This change makes eslint aware of the global IOUtils interface, such that it
may be used without having to access it from the window or otherwise declaring
the global in a special comment on a file-by-file basis.
Differential Revision: https://phabricator.services.mozilla.com/D87612
This patch adds a new property `process_type` to the launcher process failure
ping, indicating which process type the browser process failed to initialize
as a sandboxed process.
Depends on D83639
Differential Revision: https://phabricator.services.mozilla.com/D83640
This patch adds winlauncher's HandleLauncherError to DllServices
along with InitializeDllBlocklistOOPInternal so that SandboxBroker
can call HandleLauncherError.
Differential Revision: https://phabricator.services.mozilla.com/D83639
This patch defines a new macro `MOZ_USE_LAUNCHER_ERROR` and keeps
the use of `LauncherError` behind `MOZ_USE_LAUNCHER_ERROR` instead of
`MOZILLA_INTERNAL_API` so that we can selectively use `LauncherError`
in locations where `MOZILLA_INTERNAL_API` is defined.
Differential Revision: https://phabricator.services.mozilla.com/D83638
Previously, the browser dialogTemplate contained role="dialog" and the Print modal body had no role.
This caused screen readers to extraneously report "dialog, Print grouping".
Dialogs presented with commonDialog.xhtml (e.g. using Services.prompt.alertBC) did have the dialog role on the body, so screen readers would report "dialog, {dialogTitle} dialog".
To fix this, remove role="dialog" from dialogTemplate.
Instead, SubDialog now sets role="dialog" on the dialog document when it loads.
Now, screen readers report just "Print dialog" and "{dialogTitle} dialog", respectively.
Differential Revision: https://phabricator.services.mozilla.com/D87977
This change makes eslint aware of the global IOUtils interface, such that it
may be used without having to access it from the window or otherwise declaring
the global in a special comment on a file-by-file basis.
Differential Revision: https://phabricator.services.mozilla.com/D87612
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
Also fix WindowGlobalParent.drawSnapshot() to render the currently visible
viewport when called with a null rect, and clarify the webidl comment.
Differential Revision: https://phabricator.services.mozilla.com/D87971
This has been enabled on Nightly for a while and we've observed
no ill effects; ref Bug 1635667 for work to validate that it's
submitting the expected data.
Differential Revision: https://phabricator.services.mozilla.com/D87979
This rewrites the muxer. I'll explain why.
The obvious way to fix this bug is to modify UrlbarProviderSearchSuggestions so
it adds `maxHistoricalSearchSuggestions` form history results first, followed by
as many remote suggestions as there are, followed by any remaining form history
results. And in fact that's what this patch does. But the muxer isn't capable of
handling that very well, with regard to deuping SERPs and form history.
The muxer does a first pass through all results, and it builds a set of form
history suggestions. Then, as it's adding URL results in the second pass, it
excludes SERPs whose search terms are in the set. The problem is that the set
can include search terms from form history results that do not end up in the
final list of results. And that's because UrlbarProviderSearchSuggestions now
returns many form history results -- as many as `context.maxResults + 1` so that
there are enough of them to fill the view when appropriate.
This is a problem with the muxer in general. It collects a bunch of state from
all results in its first pass, even though not all of those results may end up
in the final list. Worst case, we may end up excluding results we should not
exclude. The fundamental problem is that the muxer doesn't know which results
will end up being included until it starts including results.
The key thing about this rewrite is that the muxer builds up state as it goes
along filling its buckets. If a result is excluded, then it doesn't contribute
to the state used to determine whether subsequent results should be included.
There are a couple of exceptions though where it still does build state using
all results. (1) It still determines the heuristic this way, but that's OK since
there's only one heuristic. (2) It still builds `strippedUrlToTopPrefixAndTitle`
this way. I couldn't think of a nice way around that, because AFAICT there's no
guarantee that UnifiedComplete will put the higher-ranking URL result before the
lower one. If the lower one comes first, we'd end up including it too since
`strippedUrlToTopPrefixAndTitle` would not contain the higher-ranking one at
that point.
There's one drawback of building up the state in this new way. It's the flip
side of solving the problem above. If a result depends in some way on a
subsequent result, then the state at that first result won't be accurate and the
muxer will make a bad decision about that result. There's an example of this in
test_search_suggestions.js, near the bottom of the `formHistory` task. In that
test, `matchBuckets` is defined so that general results (e.g., history) appear
before search suggestions. That means the SERP in history can't be deduped in
favor of the form history result that appears later, so both results appear. I
think that's better than the alternative of possibly deduping too aggressively.
One important thing to note is that this patch isn't restricted to search
mode. It will always include more form history results to fill out the final
list if some other higher-ranked result group doesn't fill it out
sooner. Currently `matchBuckets` is `heuristic,1,extension,5,suggestion,4,general,Infinity,suggestion,Infinity,general,Infinity.`
Since `general,Infinity` comes before `suggestion,Infinity`, this means that if
there aren't enough general results to fill out the list, then suggestions will
fill it out as much as possible. Within suggestions, remote suggestions will
fill it out first and then form history, since that's the order that
UrlbarProviderSearchSuggestions adds them in after the initial
`maxHistoricalSearchSuggestions` form history results. I think that's what we
want regardless of search mode.
Finally, this patch also breaks up `sort` into more, smaller methods. The patch
started out as a much larger version that also redesigned `matchBuckets`. That's
the main reason I split it up, but it's nice by itself I think. (I'd like to
come back to that `matchBuckets` redesign, which could now build on top of
this. The original patch is in D87830.)
Differential Revision: https://phabricator.services.mozilla.com/D87838
Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
The test abstraction meant we missed that this broke in the refactor. This
fixes the bug and makes sure the test actually tests it.
Differential Revision: https://phabricator.services.mozilla.com/D88012
Set default pref to "import" and turn off telemetry. Move browser_autocomplete_import test to reuse passwordmgr related helpers.
Differential Revision: https://phabricator.services.mozilla.com/D87595
Share ChromeMigrationUtils.supportsLoginsForPlatform for ChromeProfileMigrator.getResources and ChromeMigrationUtils.getImportableLogins.
Differential Revision: https://phabricator.services.mozilla.com/D87639
Add UA (user agent) muting, a spec-supported feature that somewhat mirrors
track enabling/disabling, except only the browser controls it. The effect
on track sinks is additive: must be unmuted and enabled for there to be
output.
Fire mute/unmute events on JS, and observably set track.muted independent
of track.enabled (reusing existing infrastructure already in use by
RTCPeerConnection tracks).
Low-level: add mDeviceMuted and SetMutedFor() modeled after mDeviceEnabled
and SetEnabledFor() as parallel device state for both camera and microphone for
symmetry and maintenance.
High-level: Only expose messages to mute/unmute camera at the moment, since
that is what is immediately required for Android in bug 1564451.
Differential Revision: https://phabricator.services.mozilla.com/D84222
The PostUpdate task must always be called as the unelevated user, even if we didn't use the service, in order to ensure that we register the WDBA. Additionally, the PostUpdate task should always be run synchronously so that the elevated and unelevated PostUpdate tasks are guaranteed to run in order. This is important since the elevated PostUpdate unregisters the task and the unelevated PostUpdate re-registers it.
Differential Revision: https://phabricator.services.mozilla.com/D87509
Add UA (user agent) muting, a spec-supported feature that somewhat mirrors
track enabling/disabling, except only the browser controls it. The effect
on track sinks is additive: must be unmuted and enabled for there to be
output.
Fire mute/unmute events on JS, and observably set track.muted independent
of track.enabled (reusing existing infrastructure already in use by
RTCPeerConnection tracks).
Low-level: add mDeviceMuted and SetMutedFor() modeled after mDeviceEnabled
and SetEnabledFor() as parallel device state for both camera and microphone for
symmetry and maintenance.
High-level: Only expose messages to mute/unmute camera at the moment, since
that is what is immediately required for Android in bug 1564451.
Differential Revision: https://phabricator.services.mozilla.com/D84222
Add UA (user agent) muting, a spec-supported feature that somewhat mirrors
track enabling/disabling, except only the browser controls it. The effect
on track sinks is additive: must be unmuted and enabled for there to be
output.
Fire mute/unmute events on JS, and observably set track.muted independent
of track.enabled (reusing existing infrastructure already in use by
RTCPeerConnection tracks).
Low-level: add mDeviceMuted and SetMutedFor() modeled after mDeviceEnabled
and SetEnabledFor() as parallel device state for both camera and microphone for
symmetry and maintenance.
High-level: Only expose messages to mute/unmute camera at the moment, since
that is what is immediately required for Android in bug 1564451.
Differential Revision: https://phabricator.services.mozilla.com/D84222
Do this by spinning the event loop until we've done the clone for
preview as appropriate.
This should be much less risky than finishing the previous patches
which would still be nice, but realistically landing them for 81 is not
going to happen.
This just returns without doing nothing in a couple cases, like when
there's already another modal dialog or such. That seems acceptable to
me, it's not clear what better way to do would be.
Differential Revision: https://phabricator.services.mozilla.com/D87484
The last line from the test in the failure log is "INFO - Leaving test bound
tabSwitch", which is the final task in the test. I'm pretty sure the test is just
doing too much rather than timing out waiting for something to happen. So let's
split it up.
Depends on D87172
Differential Revision: https://phabricator.services.mozilla.com/D87384
Whenever a top level document load finishes, if it has been five minutes since
the last time we have done so, we record telemetry about the ratio of unique
site origins loaded to the number of loaded tabs. This telemetry is split
across several different histograms, so that it can be used to approximate a
unique origins vs loaded tab count curve.
Differential Revision: https://phabricator.services.mozilla.com/D85072
Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
When adding importable logins, also add new single row autocomplete entry with fluent text and ignore it for telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D84464
See bug for justification. This patch aims to display a blank window prior to
loading/prefetching xul.dll. It also has a placeholder for drawing a
skeleton UI into that window. Note that this is disabled by default based on
a registry value, as there are still kinks to work out (for instance, what
happens if we aren't actually going to display a window, because, say, Firefox
is already running.) This just gives a basic implementation to dogfood, and
facilitates distributing work across multiple contributors.
Onto the details. The patch achieves its goal by creating a window and
assigning its handle to a static variable, which will be consumed inside
nsWindow::Create by the first toplevel window we want to make. nsWindow::Create
will take ownership of the window handle, restyle it to its own liking, and
then proceed as if everything is normal and it had created the window itself.
Differential Revision: https://phabricator.services.mozilla.com/D86263
* Add a check for `queryContext.searchMode` in
`UrlbarProviderHeuristicFallback._matchUnknownUrl`. We should not match a URL
when search mode is active, in addition to the existing check for a
restricting source.
* Move the aforementioned checks to the top of the method so that we avoid when
possible the more expensive string escaping and parsing currently at the top
of that method.
* Add a test task.
* Beef up the existing test tasks.
Differential Revision: https://phabricator.services.mozilla.com/D87189
We need to exit search mode when a page loads in the current tab. We may need to
exit search mode for page loads in other tabs too: If you're in search mode,
click a slow link, switch tabs, and the page loads in the meantime, then search
mode should be not be entered when you switch back. I don't think we handle that
case correctly right now, and this patch doesn't address that at all. That's
worth doing in another bug because I think the fix will be different.
At first I added an `onLocationChange` method to UrlbarInput that was called by
`XULBrowserWindow.onLocationChange` in browser.js [1], just like we have an
`onLocationChange` in UrlbarProviderSearchTips called by
`XULBrowserWindow.onLocationChange`. But we need to potentially exit search mode
any time `input.setURI` is called. `setURI` happens to be called by
`XULBrowserWindow.onLocationChange`, one of the several places that calls it
[2].
`setURI` is also called when switching tabs. Bug 1647899 already took care of
handling search mode for tab switches, but it would be nice to handle all this
in one place. `setURI` is also how `userTypedValue` is restored in the input,
and of course `userTypedValue` is something we need to restore when switching
tabs, just like search mode. For these reasons I moved per-tab search mode
restoration to `setURI` as part of this.
I'm also changing the name of the second parameter in `setURI`. I wasn't sure
whether it's true iff we're switching tabs, so I tracked down why that param was
added. It was added in bug 1478348, and comment 21 confirms it was added to tell
`setURI` and `XULBrowserWindow.onLocationChange` when they're being called due
to a tab switch. To make this clearer, I renamed the param and added some
javadoc for `XULBrowserWindow.onLocationChange`.
[1] https://searchfox.org/mozilla-central/rev/50cb0892948fb4291b9a6b1b30122100ec7d4ef2/browser/base/content/browser.js#5205
[2] https://searchfox.org/mozilla-central/search?q=symbol:%23setURI&redirect=false
Differential Revision: https://phabricator.services.mozilla.com/D87172
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
When a modal dialog is cancelled, the inertness for other elements
is reverted. However, in order to have the new state (non-inert)
effective, Firefox needs to do a frame flush. This flush is taken
place when it's really needed.
In browser_pioneer_us.js, we have some usage of some buttons when
the flush hasn't taken place yet, so the test fails because the
buttons are not clickable. To fix the test, we add a
getBoundingClientRect() call to force frame flushes to the
corresponding buttons.
Differential Revision: https://phabricator.services.mozilla.com/D86877
* Removing front end for the checkbox that allows users disable accessibility services
* Removing already expired telemtry probe for preferences.prevent_accessibility_services
Differential Revision: https://phabricator.services.mozilla.com/D86994
* Check both the useSystemViewer flag and the preferredAction for that mime-type when deciding to not open PDFs into pdf.js
* Don't set alwaysAskBeforeHandling to true when toggling off the "Always open in system viewer" context menu item.
Differential Revision: https://phabricator.services.mozilla.com/D86992
CLOSED TREE
Backed out changeset 17df14f0b129 (bug 1200896)
Backed out changeset 5d9e9bd12cd2 (bug 1200896)
Backed out changeset 7f016de8d52f (bug 1200896)
I can reproduce this reliably after refreshing my tree and applying the patch to
bug 1657918. It seems to be permanent in fact. The problem is that a previous
test (or the test itself, since this is a failure in verify mode) leaves the
mouse over the heuristic result, which causes it to be highlighted and show its
action text ("Search with Google"). The test is checking that the action text is
hidden.
We just need to synthesize a mousemove away from the view as the test starts. We
do something similar in a few tests already, although sometimes we use
`EventUtils.synthesizeNativeMouseMove` instead of what I use here. I tried that
function first but it didn't work here, so I went with the other one we use,
`EventUtils.synthesizeMouse` with `mousemove`.
Differential Revision: https://phabricator.services.mozilla.com/D87015
When a modal dialog is cancelled, the inertness for other elements
is reverted. However, in order to have the new state (non-inert)
effective, Firefox needs to do a frame flush. This flush is taken
place when it's really needed.
In browser_pioneer_us.js, we have some usage of some buttons when
the flush hasn't taken place yet, so the test fails because the
buttons are not clickable. To fix the test, we add a
getBoundingClientRect() call to force frame flushes to the
corresponding buttons.
Differential Revision: https://phabricator.services.mozilla.com/D86877
This excludes the heuristic for empty searches when in search mode. I haven't
heard back from Verdi yet about excluding it for all searches in search mode. We
can add that in a follow-up if necessary.
Since we're now excluding the heuristic but we want the view to remain open,
it's possible for the view to be empty while it's open. I had to make some
changes to allow that to happen. There are three cases I want to call out:
1. When the search string is empty, the view shows top sites. If you then enter
search mode and the resulting search doesn't return any results, we
previously closed the view. This patch keeps it open. An example of this
scenario is when you don't have any bookmarks and you click the bookmarks
one-off.
2. When the urlbar isn't focused, it's in search mode, the input is empty, and
the search didn't return any results, then focusing the urlbar didn't do
anything previously. This patch auto-opens the view.
3. When the input contains a single char and it's in search mode, deleting the
char previously closed the view if the empty search didn't return any
results. This patch keeps the view open.
When the view is empty, we also need to hide the one-offs' top border that
usually separates them from the results. Otherwise there are two separator lines
right next to each other, the one above the one-offs and the one at the bottom
edge of the input. I don't think there's any CSS selector that will let us
easily do this due to the DOM structure, so I added a new `noresults` attribute
on the view for this.
I had to call `context.searchString.trim()` to tell whether the search string is
empty. Since we do that in a bunch of places, I added
`context.trimmedSearchString`, and a lot of this patch is replacing those `trim`
calls.
Differential Revision: https://phabricator.services.mozilla.com/D86908
I also added types from the list of extensions we register to support on
Windows, in shared.nsh SetStartMenuInternet.
Differential Revision: https://phabricator.services.mozilla.com/D86654
This interface extends nsIDNSRecord and makes the DNS code more extensible
by allowing us to support more record types.
This change does require the consumer to be aware of the type they requested
and to QueryInterface to either nsIDNSAddrRecord for regular IP lookups,
or to nsIDNSByTypeRecord for other kinds of lookups.
Differential Revision: https://phabricator.services.mozilla.com/D86177
This patch adds the nsIDNSResolverInfo interface which is used to hold
information about the resolver to be used in a DNS resolution.
We use this to merge all of the *WithTRRServer resolve functions into one.
Passing a resolver info will use that object when appropriate. No resolver
info means that we default to using the system resolver, or the default TRR
resolver.
This patch also converts the RESOLVE_TYPE_* flags into a cenum and adds
the resolveType as a parameter to asyncResolve thus removing the need
to have asyncResolveByType methods.
Differential Revision: https://phabricator.services.mozilla.com/D86176
Robert Helmer
Michael Kaply
Kartikaya Gupta
Dão Gottwald
Keefer Rourke
Dale Harvey
Toshihito Kikuchi
Narcis Beleuzu
Jared Wein
Micah Tigley
Emilio Cobos Álvarez
Mihai Alexandru Michis
James Teh
Razvan Maries
Joel Maher
Andreea Pavel
emcminn
Tomislav Jovanovic
Neil Deakin
Harry Twyford
Scott
Cosmin Sabou
Mozilla Releng Treescript
Ryan Kelly
Noemi Erli
Mark Striemer
Tooru Fujisawa
Drew Willcoxon
Cristina Coroiu
Emma Malysz
mcrawford@mozilla.com
Dan Mosedale
Ryan VanderMeulen
Sean Feng
Gijs Kruitbosch
Sebastian Streich
Andrei Oprea
Sebastian Hengst
Thomas Wisniewski
Ed Lee
Andrea Marchesini
Mark Banner
Butkovits Atila
Julian Descottes
Jan-Ivar Bruaroey
Kirk Steuber
Bogdan Tara
lougeniac64
Christian Holler
Kenrick
Matthew Noorenberghe
Adam Gashlin
Sonia Singla
Severin
Barret Rennie
Csoregi Natalia
Akihiko Odaki
Punam Dahiya
Francesco Lodolo (:flod)
Doug Thayer
Ksenia Berezina
Rob Wu
Dorel Luca
Kris Maglione
Adam Roach [:abr]
Dave Townsend
julianwels
Julien Cristau
pbz
Zibi Braniecki
Yura Zenevich
Olli Pettay
Sam Foster
Artem Polivanchuk
Xidorn Quan
Vijay Budhram
Tim Giles
Andreas Farre
Steven Englehardt
Valentin Gosu