Make desktop UA string depend on build target.
This implements #7158 by conditionally choosing a UA string by
`#[cfg()]`-checking for `target_os = linux` and whether `target_arch` is
`x86_64` or not. Matching the behavior of Firefox, either "X11; Linux
x86_64" or "X11; Linux i686" is included.
`target_os = windows` is also checked; again as in Firefox "Windows NT
6.1; Win64; x64" or just "Windows NT 6.1" is included. The UA string
pretends to be non-WoW64 Windows 7, since there's only so much we can
detect at build time.
The existing desktop UA string that lists OS X is chosen if `target_os`
is neither `linux` nor `windows`.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8353)
<!-- Reviewable:end -->
This implements #7158 by conditionally choosing a UA string by
`#[cfg()]`-checking for `target_os = linux` and whether `target_arch` is
`x86_64` or not. Matching the behavior of Firefox, either "X11; Linux
x86_64" or "X11; Linux i686" is included.
`target_os = windows` is also checked; again as in Firefox "Windows NT
6.1; Win64; x64" or just "Windows NT 6.1" is included. The UA string
pretends to be non-WoW64 Windows 7, since there's only so much we can
detect at build time.
The existing desktop UA string that lists OS X is chosen if `target_os`
is neither `linux` nor `windows`.
Adding pipelineID to httpresponse message, clearner code for task1
Commit for Refactored task
Unit tests
Removing extra whitespaces.
Removing extra whitespaces.
Removing tabs whitespaces
Making Code tidier.
Style issues Fix
Test-tidy Fixes
I'm working on resolving https://github.com/servo/servo/issues/8213 as per the spec online and feedback in the servo channel. Note that currently I cannot build (and thus test) my code, so this is a bit of a rough first draft. I'd still like feedback on my progress, and I hope that there is another way for my code to be tested.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8218)
<!-- Reviewable:end -->
This is the strategy we'll need to take for attributes, and so this change
puts us in a position to handle attributes and state the same way.
This does mean that we stop taking care to track the situations where our
state has reverted to the original state, with no net change. I think that's
probably of negligible value though.
For some reason when I wrote this code I mixed up the rules for pseudo-elements
(rightmost, maximum of one) with those of pseudo-classes (which have no such
restriction). This caused a correctness issue which can be demonstrated with the
associated reftest modification.
Eliminate LAYERS_NEEDED_FOR_DESCENDANTS flag
This flag is no longer necessary, because stacking contexts can now
create layers lazily for content that needs to be stacked above a
layer. This should reduce the number of layers on pages, hopefully
reducing overdraw.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8334)
<!-- Reviewable:end -->
New Android suppport
r/f? @mbrubeck
No need to r+ urgently; I want to do a little bit more testing of the release build, but I'm hoping to land this bit (moving to a more sane build process) next week.
The new version of building an APK:
1) Removes the glutin-based APK builder from the link step
2) Adds a build.rs step to the build of the final Servo library that adds the native code required by glutin's android_rs_glue (e.g., `ANativeActivity_onCreate` definition)
3) Replaces the link step with a `fake-ld.sh` script that instead creates a libservo.so
4) Adds a new mach `package` step to build the APK that has some Rust code that builds the library from a set of in-tree build files
This setup fixes a number of problems:
1) We can use gdb, because we use `ndk-build`, which adds the .gdbserver info, plus we keep around all of the build files (also required by the ndk gdb)
2) We can add more Java code & hooks to handle Android intents
3) We no longer have any git submodules or the awkward two-step build with android-rs-glue
Many other setups were tried (and failed). The most obvious ones is building a libservo.so from a `dylib` target from the servo build on Android. This doesn't work because you can't have a different default lib target on one platform than others in Cargo, and you also can't pass it in from the commandline (e.g., --lib does not have a dylib arg). Additionally, if you don't go through the intermediate libservo.rlib step (which removes unused symbols), then you end up with a TON of missing symbols because our -sys crates are super sloppy about that. I spent a few weeks beginning to clean them up, but since it's something we can't easily enforce (and new -sys packages will have this problem, too, since it's only an issue with the Android loader), it made more sense to me to just have the build set up to discard those unused bits of code before they ever get to the linker, much less the loader.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8288)
<!-- Reviewable:end -->
This flag is no longer necessary, because stacking contexts can now
create layers lazily for content that needs to be stacked above a
layer. This should reduce the number of layers on pages, hopefully
reducing overdraw.
Properly resize iframe root layers
When a layer containing an iframe changes, we also need to resize the
root layer of the subpage. This ensures that content from the child
layer tree is masked to the new size.
Fixes#8301.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8322)
<!-- Reviewable:end -->
Always produce a DisplayList when processing nodes for display list
construction. StackingContexts are now added to the positioned content
section of DisplayLists. This makes the code a bit simpler and opens up
the possibility of producing a StackingContext in another section of
the DisplayList. This doesn't change behavior, but is a cleanup
prerequisite for proper inline stacking context support.
Simplify implementation of '<canvas>' 'width' and 'height' attributes.
Strictly speaking, this affects correctness for extremely large width and height values... but that's unlikely to matter in practice.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8243)
<!-- Reviewable:end -->
This should make it somewhat easier to experiment with alternative
representations in the future. To reduce churn, this commit leaves the String
field public, though.
Also, this will allow us to use the default String type to represent the IDL
USVString type, which explicitly forbids unpaired surrogates, ans as such is
a better match to the Rust String type.
