Fix simpleservo binary check on macos
<!-- Please describe your changes on the following line: -->
When compiling libsimpleservo on MacOS 11.5.2 I would get an error at the end of the process saying
```
Error running mach:
['build', '-d', '--libsimpleservo']
The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.
You can invoke |./mach busted| to check if this issue is already on file. If it
isn't, please use |./mach busted file| to report it. If |./mach busted| is
misbehaving, you can also inspect the dependencies of bug 1543241.
If filing a bug, please include the full output of mach, including this error
message.
The details of the failure are as follows:
servo.command_base.BuildNotFound: No Servo binary found. Perhaps you forgot to run `./mach build`?
File "/Users/yuriwitte/_HtmlTests/servo/python/servo/build_commands.py", line 734, in build
self.get_binary_path(release, dev, target=target, simpleservo=libsimpleservo)
File "/Users/yuriwitte/_HtmlTests/servo/python/servo/command_base.py", line 394, in get_binary_path
raise BuildNotFound('No Servo binary found.'
```
The binary is there, it's just that `get_binary_path` on `command_base.py` checks for a libsimpleservo **.so** instead of a **.dylib**. This pr fixes this check.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix: didn't find a specific issue for this, but these two are also related to file extensions on MacOS:
https://github.com/servo/servo/issues/27654https://github.com/servo/servo/issues/27318
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because: they _are_ the tests I guess?
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Update docs for VS2019 and clarify
This mostly updates Windows docs, clarifies and removes some unnecessary parts.
The long chocolatey command gives more insight into what it's doing, it still gives us the same components as before (but 2019), without VS itself.
I also used `./mach clean` a few times and had one problem due to `python/_virtualenv[version]/` not being removed completely, so I clarified what the `clean`-command does (I thought it just passes on to cargo).
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#28530 (and maybe #25845)
- [X] These changes do not require tests because it's just docs
The condition for exposing a cross-origin setter should be `CrossOriginWritable`, not `CrossOriginReadable`
Fixes `Location#href` being inaccessible from a cross-origin document.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because ___
The expression `crossOriginIframe.contentWindow.location.href = "new
href"` takes the following steps: (1) Get the setter for `href` by
invoking `[[GetOwnProperty]]` on `crossOriginIframe.contentWindow.
location`. (2) Call the setter, passing `crossOriginIframe.
contentWindow` and `"new href"`. Since the target `Location` is cross
origin, getting the setter succeeds only if the `CrossOriginWritable`
extended attribute is present on the `href` attribute, and it's present.
However, instead of `CrossOriginWritable`, `CrossOriginReadable` was
checked mistakenly.
Since `Location#href` has `CrossOriginWritable` but not
`CrossOriginReadable`, this bug rendered `Location#href` inaccessible
from a cross-origin document.
Fix compiler warnings
<!-- Please describe your changes on the following line: -->
While working on my other pull request, I noticed that there were a few compiler warnings that are easy to fix since they simply note some deprecated syntax that can be fixed with no semantic difference. I decided to quickly fix them and submit a PR.
There was also one place where an allowance of unsafe code was not being applied to the correct thing in `components/script/dom/cssrulelist.rs`. It was being applied to a macro `unsafe_no_jsmanaged_fields!` which does contain unsafe code. My understanding (and what the compiler warning states) is that applying that annotation to a macro does nothing even if the macro contains unsafe code. So what I have done is moved this annotation to apply to the entire file. I do not know if that is even necessary since the macro definition is in another file. It would be good to know since it would be best to not add extra allowances when they aren't needed. The compiler warning is below if that helps:
```
warning: unused attribute `allow`
--> components/script/dom/cssrulelist.rs:24:1
|
24 | #[allow(unsafe_code)]
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_attributes)]` on by default
note: the built-in attribute `allow` will be ignored, since it's applied to the macro invocation `unsafe_no_jsmanaged_fields`
--> components/script/dom/cssrulelist.rs:25:1
|
25 | unsafe_no_jsmanaged_fields!(RulesSource);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
```
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable) (No issue number)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because they fix compiler warnings in a way that does not change semantics except as noted.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
CI: Don't cancel the entire job matrix when one of them fails
By default, GitHub Actions [cancels][1] all in-progress jobs in a build matrix when one of them fails. This PR disables this behavior.
[1]: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they are for CI
Update script_plugin for rust-lang/rust#85296
This will update the script_plugin for the plugin interface changes in rust-lang/rust#85296.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because it is a fix for rustc changes.
The "process the iframe attributes" steps shouldn't enqueue the iframe load event steps (anymore)
Fixes `HtmlIFrameElement::process_the_iframe_attributes` (which implements [the "process the `iframe` attributes" steps][1]) queueing an element task to execute [the iframe load event steps][2], which causes another `load` event to be fired on the iframe in addition to the one asynchronously generated by [the "create a new nested browsing context" steps][3].
The following timeline shows what happens when a `src`-less `iframe` element is parser-inserted and which step this PR intends to remove. (This does not necessarily match Servo's current behavior exactly - Most notably, `T2`'s steps might run late because the "create a nested browsing context" steps' implementation actually [parses][5] a blank HTML document.)
```diff
T0 (networking task source)
| Insert the `iframe` element, causing the following steps to be executed:
| | Create a new nested browsing context
| | | Create a new browsing context
| | | | Completely finish loading the `iframe` element's `Document`
| | | | | Queue element task T2.
| |
| | Process the `iframe` attributes
- | | | Queue element task T1
- T1 (DOM manipulation task source)
- | Execute the `iframe` load event steps
- | | Fire `load` for the `iframe` element
T2 (DOM manipulation task source)
| Execute the `iframe` load event steps
| | Fire `load` for the `iframe` element
```
This bug likely originates from [a bug][4] in the specification.
[1]: https://html.spec.whatwg.org/multipage/#process-the-iframe-attributes
[2]: https://html.spec.whatwg.org/multipage/#iframe-load-event-steps
[3]: https://html.spec.whatwg.org/multipage/#creating-a-new-nested-browsing-context
[4]: https://github.com/whatwg/html/pull/5797
[5]: https://html.spec.whatwg.org/multipage/#the-end
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#24501, #15727, and the `cross-origin-objects-on-new-window.html` part of #26299
---
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because ___
This likely originates from a bug that existed in the specification[1].
A `src`-less iframe would fire two `load` events when implemented
according to an affected version of the specification.
[1]: f2839722e1
The initial document creation does not involve navigation, and it would
cause a confusion if this was done by a function which has `navigation`
in its name. This commit renames `navigate_or_reload_child_browsing_
context` to `start_new_pipeline`, and introduces a new function which
has the original name and is dedicated to handle navigation.
Implement `Location`'s custom internal methods
This PR partly resurrects #16501 and introduces the use of principals object to associate objects and Realms with origins. Using this infrastructure, this PR implements [the custom internal methods][1] of the `Location` interface, which is "maybe-cross-origin".
Unimplemented/incomplete things:
- Other maybe-cross-origin interfaces, namely `WindowProxy` and `DissimilarWindowLocation`, aren't implemented correctly yet (causing most test cases of `tests/wpt/web-platform-tests/html/browsers/origin/cross-origin-objects/cross-origin-objects.html` to fail).
- `WindowProxy`: #28556
- [The "perform a security check" operation][2] and `Location`'s non-cross-origin properties' relevant `Document` origin checks aren't implemented either (not sure if they are covered by the existing tests).
- There are a slight deviation from the standard and inefficiency in `CrossOriginGetOwnPropertyHelper`'s current implementation.
- #28557
[1]: https://html.spec.whatwg.org/multipage/#the-location-interface
[2]: https://html.spec.whatwg.org/multipage/browsers.html#integration-with-idl
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#16243 and make some progress in #2382
---
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because ___
There are code fragments in `(Method|Attr)Definer.generateArray` that
are much alike. This commit refactors them into a new method of
`PropertyDefiner` named `generateUnguardedArray` (in contrast to the
existing method `generateGuardedArray`).
It's technically safe to do because of `#[repr(transparent)]` and is a
prerequisite of having `ServoJSPrincipalsRef: Copy`, but I guess it's
not worth an `unsafe` block.
Shorten thread names to prevent information loss
The Linux kernel [imposes][1] a 15-byte limit on thread names. This means information that does not fit in this limit, e.g., the pipeline ID of layout and script threads, is lost in a debugger and profiler (see the first column of the table below).
This commit shortens the thread names used in Servo to maximize the amount of information conveyed. It also rectifies some inconsistencies in the names.
| Before | After |
|-------------------|-------------------|
| `BluetoothThread` | `Bluetooth` |
| `CanvasThread` | `Canvas` |
| `display alert d` | `AlertDialog` |
| `FontCacheThread` | `FontCache` |
| `GLPlayerThread` | `GLPlayer` |
| `HTML Parser` | `Parse:www.examp` |
| `LayoutThread Pi` | `Layout(1,1)` |
| `Memory profiler` | `MemoryProfiler` |
| `Memory profiler` | `MemoryProfTimer` |
| `OfflineAudioCon` | `OfflineACResolv` |
| `PullTimelineMar` | `PullTimelineDat` |
| `ScriptThread Pi` | `Script(1,1)` |
| `WebWorker for h` | `WW:www.example.` |
| `ServiceWorker f` | `SW:www.example.` |
| `ServiceWorkerMa` | `SvcWorkerManage` |
| `Time profiler t` | `TimeProfTimer` |
| `Time profiler` | `TimeProfiler` |
| `WebGL thread` | `WebGL` |
| `Choose a device` | `DevicePicker` |
| `Pick a file` | `FilePicker` |
| `Pick files` | `FilePicker` |
[1]: https://stackoverflow.com/questions/5026531/thread-name-longer-than-15-chars
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#28548
---
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they don't affect Servo's primary functionality in any way
Optimize repetition in workflow configuration
Replaces 20 CI jobs (`linux-wpt-{1, 2, ..., 20}`) with one with a build matrix.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they only affect the CI pipeline
mach: cleanup after dropping Python 2 support
Signed-off-by: David Heidelberg <david@ixit.cz>
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because if it builds, then it works 😄
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
The Linux kernel imposes a 15-byte limit on thread names[1]. This means
information that does not fit in this limit, e.g., the pipeline ID of
layout and script threads, is lost in a debugger and profiler (see the
first column of the table below).
This commit shortens the thread names used in Servo to maximize the
amount of information conveyed. It also rectifies some inconsistencies
in the names.
| Before | After |
|-------------------|-------------------|
| `BluetoothThread` | `Bluetooth` |
| `CanvasThread` | `Canvas` |
| `display alert d` | `AlertDialog` |
| `FontCacheThread` | `FontCache` |
| `GLPlayerThread` | `GLPlayer` |
| `HTML Parser` | `Parse:www.examp` |
| `LayoutThread Pi` | `Layout(1,1)` |
| `Memory profiler` | `MemoryProfiler` |
| `Memory profiler` | `MemoryProfTimer` |
| `OfflineAudioCon` | `OfflineACResolv` |
| `PullTimelineMar` | `PullTimelineDat` |
| `ScriptThread Pi` | `Script(1,1)` |
| `WebWorker for h` | `WW:www.example.` |
| `ServiceWorker f` | `SW:www.example.` |
| `ServiceWorkerMa` | `SvcWorkerManage` |
| `Time profiler t` | `TimeProfTimer` |
| `Time profiler` | `TimeProfiler` |
| `WebGL thread` | `WebGL` |
| `Choose a device` | `DevicePicker` |
| `Pick a file` | `FilePicker` |
| `Pick files` | `FilePicker` |
[1]: https://stackoverflow.com/questions/5026531/thread-name-longer-than-15-chars
