Update definition to:
The new definition of Triaged will be Firefox-related bugs of type
defect where the component is not
UNTRIAGED, and a non-default value not equal to -- or N/A.
Bugs of type Task or Enhancement may have a severity of N/A,
but defects must have a severity that is neither -- or
N/A.
This means edits to the references to setting release
status flags (which are now not required.)
Also switching to using :ref:`link text <target>` for
internal links because of some errors when compiling
.rst to HTML.
Fix linter error in rst
Differential Revision: https://phabricator.services.mozilla.com/D74515
This patch use the new `exception` and `hasException` field from nsIScriptError
so we can render the actual object in the message error instead of a stringified
version.
Error object are still displayed using the `customFormat` prop, so we display
only the type + message + stacktrace (but we'll have a way to inspect them
in the sidebar soon).
Existing tests were updated to fix failures, and some tests/test cases were
added to make sure we cover all the different kind of errors we can display
in the console.
Differential Revision: https://phabricator.services.mozilla.com/D71288
This should make it easier to write tests for race-conditions, as
the resolving value now indicates which event was received.
Differential Revision: https://phabricator.services.mozilla.com/D74124
When a new document is loaded in a WindowContext, various pieces of state need
to be updated in the parent process. This is currently done in an ad-hoc manner
in nsGlobalWindowOuter::SetNewDocument. This change moves the updating logic
into a common method on WindowGlobalChild.
Differential Revision: https://phabricator.services.mozilla.com/D74325
This should make the flow of how data gets into the initial WindowContext state
more clear, and allows the setting of initial synced WindowContext fields.
Differential Revision: https://phabricator.services.mozilla.com/D74324
The entire CookieJarSettingsArgs is currently being synced into every content
process, when only two fields of that structure are actually needed.
Those two fields are extracted from the CookieJarSettingsArgs and synchronized
separately to avoid leaking information such as principals into every content
process.
Differential Revision: https://phabricator.services.mozilla.com/D74258
This requires --build-peers-said-large-imports-were-ok since
third_party/rust/mp4parse/src/lib.rs is 113KB. This code is just moving from
media/mp4parse-rust to third_party/rust, so it's not really adding to net code
size.
Differential Revision: https://phabricator.services.mozilla.com/D74488
Direct Manipulation uses a different input model from processing messages that Windows sends.
Windows asks us if we want to start a direct manipulation session by sending us the DM_POINTERHITTEST message, and we call SetContact if we do. After that Windows won't send us messages until the user ends the gesture. Instead Direct Manipulation will update a transform (that's invisible to the user). We pull that transform and turn it into pan and pinch gestures.
So DealWithPopups is not called and popups don't get rolled up. Instead I call it in the function where we send all events that come from dmanip.
Differential Revision: https://phabricator.services.mozilla.com/D74215
The old code didn't handle content prevent defaulting the input.
The pinch gesture code doesn't seem to fully work properly, it will allow a little pinch zooming before halting it if content is prevent defaulting it. Not sure what is up yet.
Differential Revision: https://phabricator.services.mozilla.com/D73220
We can't just get pinch events, we need to handle both.
This state machine code is basically copied from Chrome's implementation.
Differential Revision: https://phabricator.services.mozilla.com/D71307
I had to mess with the refcounting of Display (and hence destructors) because we create a NewRunnableMethod inside Display that holds a pointer to |this|. There are versions of NewRunnableMethod that don't take a ref but I'm not sure of the lifetime of Display, so easier to just take a ref since several of the subclasses are already refcounted.
Differential Revision: https://phabricator.services.mozilla.com/D71303
The APZ was keeping a raw pointer to the controller thread. This was a dangerous exercise.
This was okay on desktop, as the controller thread was the main thread and would have outlived everything else. On Android however it's the UI thread and it could get deleted before we received a last input event.
So we use a strong pointer instead to prevent the thread from being deleted and as such, we now needs to explicitly clear it on shutdown.
This requires the various methods in APZThreadUtils to be made thread-safe so that the controller thread can be shutdown mid-air.
Differential Revision: https://phabricator.services.mozilla.com/D73830
