The issue is that we mark the second input as dirty when it gets the
reflow request (this is as expected), but then during multicol reflow
everything seems to go smoothly, but we hit this code:
https://searchfox.org/mozilla-central/rev/00977c4e37865a92f1c15572ae4aea90e934b25b/layout/generic/nsBlockFrame.cpp#3745
And bail out, leaving the line marked as not dirty, and as such the
stuff inside the page-break-inside: avoid dirty.
When it changes further, we think it's already dirty so don't bother
adding it to the dirty root list anymore and the text frame remains with
its original tiny width.
Differential Revision: https://phabricator.services.mozilla.com/D121869
Installing the Nightly MSIX packages, signed with Mozilla's Nightly
key, yields an error: "Error in parsing the app package." Unpacking
with `makeappx.exe` yields:
```
MakeAppx : error: Error info: error 8007000B: The app manifest publisher name (CN=Mozilla Corporation) must match the subject name of the signing certificate (CN=Mozilla Corporation, OU=Firefox Engineering Operations, O=Mozilla Corporation, L=Mountain View, S=California, C=US).
```
Previously, we allowed just the `CN` to vary; in this patch we make
the publisher be the entire publisher subject, and we update the
publisher details in the task definitions.
Differential Revision: https://phabricator.services.mozilla.com/D121896
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
`_install_pip_package()` may be run from `populate()`, which
is invoked from a child Python process that doesn't
have in-tree Python modules in its sys.path.
An alternate solution would be to add in-tree modules
to the sys.path, but that seemed more costly than
simply using `tempfile` and `shutil`.
Differential Revision: https://phabricator.services.mozilla.com/D119834
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
Now that the upstream Python bug has been resolved since Python 3.4 (at
the latest), we can safely remove the environment variable workaround.
Differential Revision: https://phabricator.services.mozilla.com/D119687
It's possible for a virtualenv to have an incorrect list of directories
to add to the sys.path, such as the following cases:
* Its creation got cancelled halfway through
* The list of pths changed in a new revision
* It got modified by an external tool
By validating the list of provided pths against the list of required
pths, we can ensure that the virtualenv is more dependably up-to-date.
Differential Revision: https://phabricator.services.mozilla.com/D119686
This simplifies consumer logic, since they get the parsed list of pypi
and pth requirements, as well as the list of input files that were
parsed.
One benefit of this simplification is that we no longer
recursively create VirtualenvManagers.
Note that mach_bootstrap cannot (yet) take advantage
of `ParseMachEnvRequirements` because of a dependency cycle:
* `mach_bootstrap` must set up the `sys.path` to import
`ParseMachEnvRequirements`.
* `mach_bootstrap` would want `ParseMachEnvRequirements` to
determine which paths to add to the `sys.path`.
Differential Revision: https://phabricator.services.mozilla.com/D119685
When hooking a constructor call with onNativeCall, we must only allow return
value overrides that are objects. This is convention and also what the spec
expects. This patch ensures that a primitive value here now throws.
Additionally, relax the assert that checks we aren't returning the callee from a
JSNative (for constructors) if we are currently processing a debugger eval. The
assert is still highly useful in normal cases, but fuzzing was tripping this
heuristic when using the debugger API.
Differential Revision: https://phabricator.services.mozilla.com/D121813
With the patch above, some devtools tests failed because we were trying
to call getComputedStyle(node, ":marker") (read: one colon rather than
two).
Using two colons for pseudo-elements is the right thing to do and fixes
it / removes some weird special-cases.
Differential Revision: https://phabricator.services.mozilla.com/D121858
Merge WaylandDragAndDropDataOffer and DataOffer classes to avoid potential timing issue when Drag&Drop action is set before WaylandDragAndDropDataOffer is created.
Differential Revision: https://phabricator.services.mozilla.com/D121877
Like the optimized catch-all allocation site, the unknown one doesn't get put
on the allocatedSites list if it's only used by optimized JIT code. This fix is
to check this at the end like we already do for the optimized one. Getting this
wrong doesn't really affect anything since these numbers aren't used for the
unknown alloc site.
I tried making a test for this but it took too long to overflow the count in
debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D121717
