I'm also improving waitForSourcesInSourceTree to timeout faster and have an helpful error message,
clearly highlight the unexpected or missing sources.
In source tree test, it looks like adding named eval slow things down for the quick open.
So I tuned the related assertion to avoid intermittents.
We were having intermediate updates showing up named eval instead of the source with query string.
Differential Revision: https://phabricator.services.mozilla.com/D142340
It seems as if any attempt to use PushLayer with the Blend effect causes alpha
to be incorrectly blended. Using FillGeometry explicitly with the clip geometry
and D2D1_PRIMITIVE_BLEND_COPY seems to work around this.
Differential Revision: https://phabricator.services.mozilla.com/D142501
console.compicated is modified so we only display error messages, which it's less
likely new ones will be displayed, unlike warning messages. We're also waiting
for the stacktrace of errors to be displayed to have more stable data.
Differential Revision: https://phabricator.services.mozilla.com/D141935
The issue that causes those tests fail should be fixed in Bug 1717603
However, There are still two tests have this comment "perma-fail see Bug 1600059"
- browser_privacyPreferences.js (Disabled in Bug 1745248)
- browser_editCreditCardDialog.js (Disabled in Bug 1664620)
The reason we don't enable the two tests is because those tests were disable in
different bugs and it seems there are other issues causes we disable the tests.
Differential Revision: https://phabricator.services.mozilla.com/D141591
we directly use what's returned from the `Frame` component. We allow to pass
an extra `className` prop to it so we can still add the `message-location` class
that is used in the console.
Differential Revision: https://phabricator.services.mozilla.com/D142097
This simplifies the markup a bit, and hopefully could contribute to improve
layout and styling performance in the console.
Differential Revision: https://phabricator.services.mozilla.com/D142096
A completely straightforward adaptation of existing code for 32-bit.
I opted not to do this for baseline, indeed I think that the implementation
of this for baseline on mem32 was a bridge too far. Discuss.
Differential Revision: https://phabricator.services.mozilla.com/D142040
This supports any try-finally that doesn't emit a `JSOp::Retsub`. Currently that means that we don't support break, continue, or return inside the try block, but there's room to fix that in the future.
Differential Revision: https://phabricator.services.mozilla.com/D142119
This is mostly modeled after the catch code. The main difference is that finally expects to resume in code where there are two additional values on the stack, so we store the exception in the ExceptionBailoutInfo and write it into the stack frame in BaselineStackBuilder.
Differential Revision: https://phabricator.services.mozilla.com/D142118
At the end of a try block, we currently jump to the finally block, retsub back to the end of the try block, and then immediately jump to the code following the finally block. The same is true for the end of a catch block.
As a first step in cleaning this up, this patch rewrites the try and catch blocks to instead push a resume index that will jump directly to the code following the finally block, without the extra hop. Prior to this patch, a try block looked like this:
```
Try
[Body]
ResumeIndex <N> // push resume index for jump target below
False
Goto <N> // jump to finally block
JumpTarget // target of ResumeIndex
Goto <N> // jump to code after finally block
```
After this patch, a try block looks like this:
```
Try
[Body]
ResumeIndex <N> // push resume index for code after finally block
False
Goto <N> // jump to finally block
```
One subtle note: in TryEmitter::emitEnd, we emit the jump target first and then allocate the resume index based on the last target offset. This is necessary because there's a jump target emitted by the InternalIfEmitter in the finally block, and `emitJumpTarget` [will alias consecutive jump targets](https://searchfox.org/mozilla-central/rev/eeeba8183d3268e0d563c2becf9f4adc21a37368/js/src/frontend/BytecodeEmitter.cpp#392). If we allocated the resume index first, like the existing code in `jumpToFinally`, then it would not point to the jump target.
Differential Revision: https://phabricator.services.mozilla.com/D142036
