<!-- Please describe your changes on the following line: -->
When an html anchor has a non-self target, fire a `mozbrowseropenwindow` event.
---
<!-- 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
- [X] These changes fix#11539.
- [X] These changes do not require tests because we don't have the infrastructure for mozbrowser testing yet.
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: bdecfa13d2114281472d5df4548a8faaf8a5bd87
This was easier to throw together than per-attribute/method support, and it gets rid of some nonstandard properties from our globals.
Fixes#7626.
r? @Ms2ger
Source-Repo: https://github.com/servo/servo
Source-Revision: 8255e74a61d62be94ef53caa9ebe6cd5082dcb4d
Part of #10334. Once #10824 lands, we can include the panic reason and backtrace in the error report.
Source-Repo: https://github.com/servo/servo
Source-Revision: 990dd72da7d69ffa98a5d1b266f48d14d24852aa
This might be a bad idea, especially on the webidl side. However, we started talking about the idea that modelines are a lint error (https://github.com/servo/servo/issues/10719), and these changes would be required before enabling a modeline lint.
If it bitrots, it's easy to recreate with
```
find * -type f -exec sed '/- Mode:/d' -i {} +
find * -type f -exec sed '/ vim:/d' -i {} +
git checkout -- python/tidy/servo_tidy/tidy.py
git checkout -- python/tidy/servo_tidy_tests/spec.webidl
git commit -a
```
Source-Repo: https://github.com/servo/servo
Source-Revision: dff217c2e3ff0b77eeebf62d36c2bf57c044cf14
This is a change in the Browser API itself.
Before, on `mozbrowserlocationchange`, we would call `getCanGoBack()` and `getCanGoForward()`. Two asynchronous methods called on an event, which doesn't make much sense, especially because we already know on `mozbrowserlocationchange` if we can go back/forward. So here I'm adding 2 new properties to the event to tell if the iframe can go back/forward.
The way `event.detail` is defined also changed. Before, `event.detail` was a string (the new uri), now it's an object (`{uri:String,canGoBack:bool,canGoForward:bool}`).
This is one of the design flaw of the early Browser API: not using objects for the detail property, making it hard to extend the event payload.
So that makes this event not backward compatible. We can:
1. just don't care. It's up to the client to test if event.detail is a string or not if it needs to be compatible with Gecko
2. fix it in Gecko. The client will still have to test `event.detail` to make it compatible with older version of gecko
3. rename `mozbrowserlocationchange` to something else (`mozbrowserlocationchange2` ?)
Please advise.
Source-Repo: https://github.com/servo/servo
Source-Revision: db63aa423fcfc87e47d9250680737ef11d2c3d26
Fixes#8544
No test yet. Is there a way to mock a https connection?
Also, I wish I could use the `HTTPSState` enum instead of a `String` when calling `trigger_mozbrowser_event` (https://github.com/servo/servo/compare/master...paulrouget:securitychange?expand=1#diff-30a18e04d7e0b66aafdf192e416cad44R306) but that would require `constellation_msg.rs` to know about `HTTPSState`, which is defined in `document.rs`, which would add a dependency to `components/msg`. I could define `HTTPSState` somewhere else maybe? Or maybe it's fine to use a `String`. But then, should I use the HTTPSState strings (`"modern/deprecated/none"`) or the mozbrowser strings (`"secure/insecure/broken"`) (as it is now)
Source-Repo: https://github.com/servo/servo
Source-Revision: 3d63f09361afa80b9d5c4f6b192c9bd8936094b7
Currently, there are a few linting functions that only run on certain
filetypes (determined by the file extension). Prior to this commit, the
special cases were handled in a parent function with a conditional. This
commit changes the system so each linting function gets passed a
filename so the function can determine whether it should run or not
based on the file extension.
I also refactored flake8 linting slightly. From what I've read so far of
the code, flake8 itself will only print the results directly to stdout
(though the linter would report the quantity of errors detected).
Prior to this commit, we would let flake8 print directly to stdout and
just determine if there were >0 errors reported. This commit (sort of
hackily) temporarily captures stdout when we call flake8 so we can do
what we want with the output, allowing us to `yield` the line number
and message like we do with the other linting functions.
In my opinion, both of these changes isolate specific behaviors/checks
into their respective linting functions instead of having them handled
at a more global level.
In addition to the changes above:
* The whitespace linter now runs on WebIDL and TOML files
* The license header linter now runs on WebIDL files
Source-Repo: https://github.com/servo/servo
Source-Revision: 7c8922c0c39616559b580b4a363ebe2a8c6b3ba8