These assertions were removed from the spec when supporting multiple built-in
calendars other than the ISO-8601 calendar was allowed even without ECMA-402
integration.
Depends on D211185
Differential Revision: https://phabricator.services.mozilla.com/D211186
Replace the string calendar with an enum class in preparation for adding support
of more built-in calendars. (This will happen in a follow-up bug.)
Depends on D211184
Differential Revision: https://phabricator.services.mozilla.com/D211185
The calendar identifier will generally be a linear string, so if we directly
return a linear string from `ToTemporalCalendarIdentifier`, we can simplify
some callers.
Depends on D211183
Differential Revision: https://phabricator.services.mozilla.com/D211184
Simplified debouncing logic to avoid depending on DeferredTask. Add missing `aria-label` which is needed for the edge case of showing a search box without placeholder.
Differential Revision: https://phabricator.services.mozilla.com/D210701
Move style persistence from XULstore to SessionStore.
Follow up bug to fix persistence of sidebar when only a new tab is open and window is closed, and its
accompanying test `browser_sidebar_persist.js`: Bug 1898613
Depends on D207048
Differential Revision: https://phabricator.services.mozilla.com/D207787
This changes the shell's internal thread pool to dispatch tasks to helper threads in
a fixed order rather than by threads picking up each task depending on which is
the first to get scheduled. In other words, if there is only ever at most one
task in the system then all tasks will be run on the first pool thread; if
there are at most two then the only the first two threads will be used.
This results in a noticable improvement on the splay benchmark on my linux
system, probably due to cache effects. This patch only affects the shell but it
indicates that it may be preferable for TaskController to work in a similar
way.
This removes JS::DispatchReason which is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D206764
One thing I noticed while working on this was how much of the internals of
GlobalHelperThreadState are public. Code that access these internals can be
refactored into methods which also simplifies this code.
Differential Revision: https://phabricator.services.mozilla.com/D206763
After a task has been dispatched to the thread pool it's not possible to cancel
it. Don't run such tasks on the main thread but wait instead.
This does make a difference to parallel marking on the linux system I tested
on, so the patch changes that to explicitly use the main thread as one of the
marking threads (this always happened previously since we don't release the
lock before waiting on it). I believe this is because the core the main thread
is running on is likely to already have a bunch of the relevant data in its
caches.
Differential Revision: https://phabricator.services.mozilla.com/D206761
This removes the check from checkTaskThreadLimit that always allows tasks to
start if |maxThreads == threadCount|. Previously there was a further check on
the number of dispatched tasks that limited this to the number of threads but
that was removed in the previous patch. I don't know why this check was ever
there.
Without this change we will dispatch helper thread tasks for all Ion
compilations which can result in a very large number of tasks being dispatched.
Combined with the fact that this patch stack means that we can't cancel tasks
after they've been dispatched but before they start running this meant that
some tests were timing out.
The patch also simplifies the rest of that method as I've always found it
confusing.
Differential Revision: https://phabricator.services.mozilla.com/D209918
This changes the helper thread system to pick the task to dispatch up front and
pass it though to TaskController via the callback.
One issue that came up was that the memory containing IonCompileTasks is
protected until the task starts running, but we may now trace these before that
happens.
Differential Revision: https://phabricator.services.mozilla.com/D206762
The parent global object of a webpage utilizing the WebCodecs API can go
away while WebCodec decoder (or encoder) output is in flight. If the
parent object is no longer available, all subsequent output callbacks
must be canceled.
Differential Revision: https://phabricator.services.mozilla.com/D211448
This patch ensures that OutputEncoded*Data does nothing if `AutoJSAPI`
initialization fails due to the absence of a parent object. As a result,
all encoder output will be dropped in such cases.
Differential Revision: https://phabricator.services.mozilla.com/D211447
This patch introduces a test that simulates the steps outlined in bug
1897631 to reproduce a crash caused by the absence of the parent global
object. The parent object goes away when the page is refreshed, while
there are pending encoder or decoder output callbacks queued for
execution. In such cases, when these output callbacks are executed, they
fail to create the necessary WebCodecs elements due to lack of the
required parent global objects. Those objects were removed during the
page reload.
However, one drawback of using a page refresh in the test is that it
doesn't guarantee the crash will occur 100% of the time. There is a
slight chance the test will pass by luck. Nevertheless, having a test
that works 90% of the time is better than having no test at all.
Differential Revision: https://phabricator.services.mozilla.com/D211470
