The formatters in mFormatCache are only valid for the locale in which they were
created. Currently the tests change mLocale directly but leave the cache in
place which can lead to incorrect test results depending upon which tests are
executed. This is not a problem outside of the tests because mLocale is normally
only set once during the call to Initialize() which will not change the current
locale once it is set.
Differential Revision: https://phabricator.services.mozilla.com/D93009
This adds a method to get the calendar symbol for a month or a weekday in long
or short form. We'll add more fields and styles in the future, the current patch
provides enough functionality to replace the selectors for kDateFormatMonthLong
and kDateFormatWeekday, which are currently used to retrieve display names by
calling FormatPRExplodedTime.
Differential Revision: https://phabricator.services.mozilla.com/D93008
There are a couple of issues that still need to be resolved, but I think this is ready for review:
- This patch does not use the icon in the UX spec. I'm waiting on that icon and just using the engine icon in the meantime.
- We also don't have a spec for how the result should wrap at narrow window widths, so I put some placeholder behaviour in.
- It appears dynamic results are incapable of overriding the CSS for normal Urlbar classes unless !important is used, regardless of specificity. Thus a few rules in dynamic-tabToSearch.css use !important, which isn't ideal. It appears this is because dynamic result stylesheets are [loaded](https://searchfox.org/mozilla-central/rev/919607a3610222099fbfb0113c98b77888ebcbfb/browser/components/urlbar/UrlbarView.jsm#1783,1785,1802) as `AGENT_SHEET`s. Changing that value to AUTHOR_SHEET allows the dynamic result CSS to override the normal Urlbar classes without !important. This strikes me as a tough issue. dynamic-tabToSearch.css is an agent sheet since it's provided by the browser. I do wonder if its defensible to load it as an author sheet since it will usually be loaded by an extension/external developer (this might be a stretch :). I'm not well-versed enough in the technicalities here to really make a call, so I'm eager to hear if @dao or @adw have any thoughts on how to resolve this issue.
Differential Revision: https://phabricator.services.mozilla.com/D93015
See the comment.
https://phabricator.services.mozilla.com/D90808 made it so that we
reused the print document (and thus <browser>) to do the actual print
job.
When a print job finishes, we call window.close(), which is used as a
signal to the front-end to clean up the <browser> element. Before that
patch we sent that signal to the browser created in printUtils.js, but
afterwards we send it to the preview window which causes this badness
when the event bubbles up.
Ignoring it effectively restores the previous behavior, so let's do it.
Differential Revision: https://phabricator.services.mozilla.com/D93499
Check that when removing iframes, we're notified about the worker unregistration,
and check that the target list works as expected when we have multiple iframes
on same origin (both remote and same-origin as main document).
Differential Revision: https://phabricator.services.mozilla.com/D88769
This patch adds support for dedicated worker targets in the Watcher actor.
Shared and Service workers are not handled yet.
In a similar manner to what we already have for frame targets, we add a worker-helper
file that will communicate with a JsWindowActor pair spawned on each document,
that will manage workers (DevToolsWorkerParent/DevToolsWorkerChild).
For a given document, the DevToolsWorkerChild will enumerate the existing workers
related to it, as well as add an event listener to be notified when workers are
being registered and unregistered, and communicate that back to the DevToolsWorkerParent
on the main thread, so worker targets creation and destruction are notified by
the Watcher actor (via target-available-form and target-destroyed-form events).
When a worker is created, the DevToolsWorkerChild for the document the worker
was spawned from will create a WorkerTargetActor, that will live in the worker
thread (using worker-connector.js), passing it resources the Watcher is currently
listening for. It will also handle communication between the main thread and the
worker thread, when the watcher listen to new resources (or stop watching resources).
A WorkerTargetFront is created so the client can be notified about available
resources (via the resource-available-form event, emitted from the worker target).
Tests are added in the next patches of this queue.
Differential Revision: https://phabricator.services.mozilla.com/D85399
It looks like the combination of cupsGetDests and filtering
CUPS_PRINTER_DISCOVERED filters a certain type of printers which shouldn't be
filtered.
As I wrote [1], cupsEnumDests didn't filter out a printer which hadn't been
configured in the system, but the printer didn't make opening the print preview
window slow at all, so it would be better than the case where users can't use
printers at all.
[1] https://phabricator.services.mozilla.com/D90508#2928340
Differential Revision: https://phabricator.services.mozilla.com/D92892
<object> and <embed> elements can handle a number of media-like resources, like images, videos, audio, PDFs. This patch adds tests for all but video. See bug 1670803 for video tests.
Differential Revision: https://phabricator.services.mozilla.com/D93273
Actually software keyboard is opened by the following situations.
- Click event in editor
- Get new focus event.
Ace editor has small <textarea> element to handles some input events.
When clicking editable-like area (but this isn't ediable on Ace editor),
mousedown handler calls `event.preventDefault()` then set focus to
<textarea> element. So editor doesn't get click event and focus is still
keep in <textarea> element. At finally, we cannot open software keyboard
again since focus isn't changed.
So even if focus isn't changed, we should call SetInputContext to open
software keyboard.
Also, actually we doesn't have generic test code for notification of
software keyboard change (bug 1670539). I will add the test by bug 1670539.
Differential Revision: https://phabricator.services.mozilla.com/D93326
This is a fairly trivial change. It's been on Nightly for quite a while
now. This will in practice turn on late write checking for early beta, as
the IOInterposer is not active past that point. We will then analyze any
late write reports and see if anything new turns up which we haven't
already seen and classified as harmless in Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D93536
This allows apps to modify the header filtering behavior, and introduces a safe
default (CORS safelisted).
Deprecated `loadUri` methods still maintain the old behavior so that we don't
inadvertently introduce bugs in apps.
Differential Revision: https://phabricator.services.mozilla.com/D91983
Dan Minor
Jonathan Kew
Butkovits Atila
Harry Twyford
Sebastian Hengst
smolnar
Valentin Gosu
Emilio Cobos Álvarez
Ben Delevingne
Andi-Bogdan Postelnicu
Christian Holler
Christoph Kerschbaumer
Marco Bonardo
Csoregi Natalia
Nicolas Chevobbe
alwu
Hiroyuki Ikezoe
David Parks
Cameron McCormack
Razvan Maries
Andrew Osmond
Makoto Kato
Doug Thayer
Agi Sferro