summit2.html is a two pane demo of rust logo and matrix math.
summit3.html is a three pane demo adding longcat.
summit-fail.html is thw two pane demo with failing page on the right.
summit2.html is a two pane demo of rust logo and matrix math.
summit3.html is a three pane demo adding longcat.
summit-fail.html is thw two pane demo with failing page on the right.
Add selector matching, style structs, cascading. The matching is quite naive and has many low hanging fruits for optimization. No pseudo-class (except `:not()`) is implemented yet, but those are easy to add as needed.
Next step is to update the layout code to use this and drop netsurf-css.
(Most of the +7066 lines stat is for bootstrap.css, added as a test.)
Fixes#1004. I haven't seen the other ones be reported, but I saw often saw `task <unnamed> failed at 'RenderChan.send: render port closed', /home/jdm/sdb/servo/src/components/gfx/render_task.rs:76`, `task <unnamed> failed at 'receiving on closed channel', /home/jdm/sdb/servo/src/compiler/rust/src/libstd/rt/comm.rs:487`, and failed assertions due to layout running after we had begun tearing down the window.
This appears to fix the problem with the Rust logo stopping during the demo.
Though this is the right way to spawn a SpiderMonkey thread, I'm not entirely sure why this fixes the problem in all scenarios. With enough threads (i.e. `RUST_THREADS=32`), and running with some Rust patches that are available on master (which I applied during testing), I would expect work stealing to not allow starvation here. In my tests though I see the problem even with lots of threads, so this may yet indicate a scheduler bug. Still, SpiderMonkey should get its own thread.
This cleans up configure and Makefile.in so that things build correctly on Darwin.
This needs https://github.com/mozilla-servo/nss/pull/6 before it can be merged. Please hold any r+ until that lands and I push the submodule update.
Fixes#967 and #965
This has been wrong for a long time. Previously, only the pipeline associated with the root frame evicted would be shut down. 1) It shouldn't necessarily be closed, because there could be references to it still in the navigation context, and 2) Presumably none of the children pipelines of the root frame were ever exiting.
It's hard to test this right now because #965 covers up other pipeline exiting issues, but when that's fixed, a pathological case in which things would have broken down would be:
1) Load a page with an iframe that contains a link
2) Click the link
3) Press backspace to navigate back
4) Navigate to any new page, at which point the forward page would be evicted from the navigation context, and the outer frame's pipeline would be shut down improperly.
5) Press backspace, at which point there is no longer a pipeline for the old page, because it was shut down prematurely. Presumably this would cause a crash.
I also changed the FrameTree function ```find_mut``` to ```find``` because find_mut implies it's doing something to cause mutability, but the mutability is caused by the type of object being iterated over, nothing else.
Additionally, script was exiting completely when receiving an exit message. Instead, it needs to handle exit messages according to who sent it. It should only close the subframes of the frame whose pipeline sent the exit message. This is now fixed.
Inexplicably, script was also closing the compositor upon receiving an exit message. This doesn't seem like it'd ever be the right thing to do. *Edit: this is _only_ the right thing to do when received from the window.* I've fixed that. I don't think anyone shuts down the compositor now. *Edit: the script shuts down the compositor only when receiving an exit from the window.*
