Make the "is hidden due to non-collapsed selection" use the regular
caret-hiding mechanism, so that we make sure nsCaret and paint are
consistent on their caret visibility.
As part of this simplification:
* Remove LookAndFeel::IntID::ShowCaretDuringSelection, it's 0 on all
platforms.
* Remove nsCaret::IsMenuPopupHidingCaret. Is really broken as per the
comments (it assumes single-process mode, doesn't deal with shadow
dom, and it's not like it's particularly useful anyways since the
menu popup could be semi-transparent or what not).
Differential Revision: https://phabricator.services.mozilla.com/D205557
Table captions have a similar issue as column spanners, where their
parent might not be the in the subtree of the style frame of its
ancestors. In particular, a repaint posted to a table that
doesn't cause a repaint in the table wrapper might not cause a repaint
of its captions.
Handle table captions like we treat out of flows and spanners, and add
more comments around this set-up.
Differential Revision: https://phabricator.services.mozilla.com/D205504
There is two situatoins cause pending events in the worker thread after Worker status changes to "Dead."
1. The WorkerPrivate::DoRunLoop is never executed.
This is the case where the worker initialization on the worker thread fails. And then WorkerPrivate::RunLoopNeverRan() would be called for handling these fail cases. However, WorkerPrivate::mPreStartRunnables had already dispatched when WorkerPrivate::SetWorkerPrivateInWorkerThread() is called, so when the moment executing WorkerPrivate::RunLoopNeverRan(), mPreStartRunnables must in the worker thread already. CompileScriptRunnable is one of these runnable.
2. Worker enters into DoRunLoop(). The WorkerThread can be held as nsIThread or nsIEventTarget by
nsCOMPtr<nsIThread> thread = NS_GetCurrentThread()
thread->Dispatch(myRunnable);
We don't block these runnable dispatchings after the worker's status changes to "Dead" because some objects, such as cycle_collector, need to complete their shutdown after the worker's shutdown. So ExternalWrappedRunnables(wrapped here) shows up in the dispatching stack when we hit the assertion. The original runnable is from everywhere and is related to Worker.
To fix case 1, the patch wants to handle the pending events in WorkerPrivate::RunLoopNevenRan() correctly. So, call ProcessPendingEvents if needed.
To fix case 2, we process the pending events before setting WorkerThread::mWorkerPrivate as nullptr. I think this is a correct time point because I think any other shutdown jobs should be finished before we detach the WorkerPrivate from the Worker thread.
Differential Revision: https://phabricator.services.mozilla.com/D203551
We are aware of the fact that std::sort does no bounds checks at all and
can be derailed by bad comparators, but we assume we will catch bad
comparators with tests in DEBUG builds and can go for full speed here.
Differential Revision: https://phabricator.services.mozilla.com/D205604
As chromium is no longer used and chromium as release is replacing it, we are removing all references to it to not confuse people
Differential Revision: https://phabricator.services.mozilla.com/D204821
It's natural for the system to be less responsive when saturated by an
all-cores workload like compilation.
However, we can use process priority to downgrade our saturating workloads,
so that normal system operation has higher relative priority.
I tested once (totally scientific!) and got a build time for
`./mach build --priority idle` not-worse-than for
`./mach build --priority low` (the current default).
```
[clobber; configure]
PS C:\dev\mozilla\gecko7> ./mach build --priority idle
[...]
To view a profile of the build, run |mach resource-usage|.
7:59.70 Your build was successful!
[clobber; configure]
PS C:\dev\mozilla\gecko7> ./mach build
[...]
To view a profile of the build, run |mach resource-usage|.
8:10.34 Your build was successful!
```
I don't generally expect builds to be faster when asking for lower priority,
but if it happens too for free, that's cool too.
But the main goal here is improved system responsiveness.
Differential Revision: https://phabricator.services.mozilla.com/D205374
Per the IDL, this method returns enum ProviderOptions.
Strictly speaking, that's not correct because this is actually a bit field combining values from the enum, rather than returning only a single value from the enum.
It seems some compilers are more strict about this and thus fail with an error like: assigning to 'enum ProviderOptions' from incompatible type 'int'
To work around this, static_cast the value before returning it.
Differential Revision: https://phabricator.services.mozilla.com/D205667
When printing tables, if a table row group is split across the page boundary,
its table-cell descendants with `vertical-align:baseline|middle|bottom|` do not
align as expected and there might be data loss. Currently, we reflow the table
row frames first, and then call DidResize() [1] to move table cells to their
vertical-align positions via BlockDirAlignChild() [2] . This is fine if the
table is in gallery mode or can fit in one page, but it doesn't work if it is
across the page boundary.
To fix this properly, we need to rewrite the table fragmentation code so that
the a table cell is reflowed in its aligned position with a correct constrained
available bsize. In the meantime, this patch works around the data loss by
forcing table-cells to use `vertical-align:top`. This is a hack, but it also
matches Google Chrome's current behavior. I feel this is a good interim solution
to improve our printing quality.
[1] https://searchfox.org/mozilla-central/rev/2537e5eaafaab9a7ef6be5cfc8e9b1e2c747fdfd/layout/tables/nsTableRowGroupFrame.cpp#1119-1125
[2] https://searchfox.org/mozilla-central/rev/2537e5eaafaab9a7ef6be5cfc8e9b1e2c747fdfd/layout/tables/nsTableRowFrame.cpp#370-372
Differential Revision: https://phabricator.services.mozilla.com/D205538
We should always keep cached capabilities in the MFCDM process so that
we won't need to regenerate capabilities when asking that from different
content processes.
Differential Revision: https://phabricator.services.mozilla.com/D205393
Changed
* `--color-background-*` are now part of the group of `--background-color` tokens
* `--box-background-color` is now part of the group of `--background-color` tokens as `--background-color-box`
* `--color-canvas` is now part of the group of `--background-color` tokens as `--background-color-canvas`
* `--border-interactive-*` are now part of the group of `--border-color` tokens and consequently now start with `--border-color`
* `--color-error-outline` is now an outline-specific token as `--outline-color-error`
* Comment headings were cleaned up as to follow the existing standard
* Better documentation behind the difference of "Base", "Application", and "Component" tiers in the design tokens documentation
* Tokens files are alphabetized
Removed
* `--outline-color-error` had duplicates in both high contrast mode media queries, so its value under `forced-colors` was removed
* "Base" and "Application" headings in tokens files were removed in order to lean in on the alphabetical order organization of token groups and promote a cleaner file and less confusion
* Documentation was edited down to not incude any guidance that we don't adhere to
* Remove duplicate interactive border color high contrast mode tokens in `tokens-brand.css` in favor of `tokens-shared.css`
* Remove `--button-border-color-primary` duplicate in `tokens-brand.css`
* Remove duplicate `--button-text-color` in `tokens-shared.css`
Differential Revision: https://phabricator.services.mozilla.com/D202767
When tracing strings in the whole cell buffer, track all tenured dependent -> nursery string edges for later sweeping, and update the characters pointer if the base string's chars move out of the nursery.
Differential Revision: https://phabricator.services.mozilla.com/D203865
Added in some code to expose the path to the os default application. Tested via tests on Windows. Mac and Linux will use the nsMIMEInfoImpl which will supply the functionality for them and be tested with the auto-tests.
Differential Revision: https://phabricator.services.mozilla.com/D204306
Some code to exercise this in the browser console:
```
{
const printNames = async (appList) => {
let buffer = "Start:\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
buffer += app.executable.leafName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
let prettyName = await app.prettyNameAsync();
buffer += prettyName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
buffer += app.executable.displayName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
if (AppConstants.platform == "win") {
let file = app.executable;
if (file instanceof Ci.nsILocalFileWin) {
try {
buffer += file.getVersionInfoField("FileDescription");
} catch (e) {
}
}
}
buffer += "\n";
}
buffer += "\nEnd\n";
console.log(buffer);
};
const lazy4 = {};
XPCOMUtils.defineLazyServiceGetters(lazy4, {
gMIMEService: ["@mozilla.org/mime;1", "nsIMIMEService"],
});
let mimeInfo4 = lazy4.gMIMEService.getFromTypeAndExtension("text/html", "html");
if (mimeInfo4.hasDefaultHandler) {
console.log(`HasDefaultHandler = true`);
console.log(`Description = ${mimeInfo4.defaultDescription}`);
} else {
console.log(`HasDefaultHandler = false`);
}
let appList4 = mimeInfo4.possibleLocalHandlers || [];
console.log("appList4 = ");
console.log(JSON.stringify(appList4));
printNames(appList4);
}
```
That produces output that can be seen in a pretty form here:
https://docs.google.com/spreadsheets/d/1OvtrZgMlPMJO4Wgu6wwAYvm89orj9HdS_tsDxYn7yrA/edit#gid=0
This does not fix-up things so that all calls to getName() on the LocalHandlerApp are switched to prettyNameAsync. That work is tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=1884267
Differential Revision: https://phabricator.services.mozilla.com/D203876
