This makes our builds a bit more reproducible. Without it when processing
#include "IPC/IPCMessageUtils.h
we end up in
#include "ShadowLayers.h"
which in the final XUL translates into the symbol (run nm -a to see it):
- 00 0000 SOL ../../../../gfx/layers/IPC/ShadowLayers.h
now when some file in gfx/layers/ipc does
#include "ShadowLayres.h"
the file found is the local one with the lowercase directory name and we end up
with
- 00 0000 SOL ../../../../gfx/layers/ipc/ShadowLayers.h
--HG--
extra : rebase_source : 96c68f6a3448eedaa280039960df911a9c707cac
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginplaypreview.js | Test 1a, the overlay about: content is expected
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginplaypreview.js | an unexpected uncaught JS exception reported through window.onerror - TypeError: Components.classes is undefined at jar:file:///c:/talos-slave/test/build/firefox/omni.ja!/chrome/toolkit/content/global/about.xhtml:38
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginplaypreview.js | an unexpected uncaught JS exception reported through window.onerror - TypeError: Components.classes is undefined at jar:file:///c:/talos-slave/test/build/firefox/omni.ja!/chrome/toolkit/content/global/about.xhtml:38
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginplaypreview.js | Found an unexpected tab at the end of test run: jar:file:///c:/talos-slave/test/build/firefox/omni.ja!/chrome/toolkit/content/global/about.xhtml
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginplaypreview.js | Found an unexpected tab at the end of test run: chrome://mochitests/content/browser/browser/base/content/test/plugin_test.html
CLOSED TREE
The nsCSSValue in nsGenericHTMLElement::MapBackgroundInto is a temporary. This causes a problem after Bug 697230 landed, because the nsCSSValue::Image we put into that value is destroyed once we're done doing style stuff. Previously the nsImageLoader would grab the request off the nsCSSValue::Image and hold it alive. Bug 697230 changed the behavior here; now when the nsCSSValue::Image is destroyed it tells the image loader to drop the request. The result is that all the references to the request are dropped and the frame is never told it has a background.
The solution is to keep the nsCSSValue::Image alive longer. This patch adds two new types of nsAttrValue. The first is an nsCSSValue::URL. A ParseBackgroundAttribute method is added on nsGenericHTMLElement that the relevant elements (body/td/th/table/tr/tbody/thead/tfoot) call that parses background into an nsCSSValue::URL. The second is an nsCSSValue::Image. nsGenericHTMLElement::MapBackgroundInto attempts to convert the nsCSSValue::URL into an nsCSSValue::Image by kicking off the image load. The result is that image loads are only started when the element is actually visible. This also mirrors the way background-image works. This also allows us to fix two longstanding bugs in this code. Since MapBackgroundInto doesn't have a pointer to the actual element, it relied on grabbing the principal of the document. Now we can grab the principal of the node in ParseBackgroundAttribute. MapBackgroundInto also has no way to get at the element's base URI (to honor xml:base), which is now possible in ParseBackgroundAttribute.
nsCSSValue::[Image|URL] have also been moved to be mozilla::css::[Image|URL]Value. nsAttrValue.h is included in external linkage code, so it can't include nsCSSValue.h to get the declarations of nsCSSValue::[Image|URL], and nested classes can't be forward declared. Moving the classes to a namespace solves the problem.
Finally some old inoperative quirks mode code was removed. This code has done nothing since Bug 273078 was landed in 2004.
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginplaypreview.js | Test 1a, the overlay about: content is expected
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginplaypreview.js | an unexpected uncaught JS exception reported through window.onerror - TypeError: Components.classes is undefined at jar:file:///c:/talos-slave/test/build/firefox/omni.ja!/chrome/toolkit/content/global/about.xhtml:38
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginplaypreview.js | an unexpected uncaught JS exception reported through window.onerror - TypeError: Components.classes is undefined at jar:file:///c:/talos-slave/test/build/firefox/omni.ja!/chrome/toolkit/content/global/about.xhtml:38
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginplaypreview.js | Found an unexpected tab at the end of test run: jar:file:///c:/talos-slave/test/build/firefox/omni.ja!/chrome/toolkit/content/global/about.xhtml
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginplaypreview.js | Found an unexpected tab at the end of test run: chrome://mochitests/content/browser/browser/base/content/test/plugin_test.html
--HG--
extra : rebase_source : e000988677d466b4796c5b2a51968f586743e6db
This patch actually converts over most of the existing native CC classes
to use the participant. This is done by converting them to use
the newly generalized nsCycleCollectingAutoRefCnt instead of their usual
ref count.
This is mostly a matter of defining new macros defining AddRef() and Release()
for native CC classes with the CC ref count.
nsTimeout is left as a legacy native CC class because it is a weird class,
but hopefully eventually it too can be converted over. See bug 774874.
We currently set this for system globals and anything whose parent
chain leads to a system global. Maybe this was relevant before, but
with CPG this is just equivalent to asking whether the object is in
a system compartment. And the only place where we _check_ this bit
is immediately after checking for a system compartment, in
WrapperFactory. So AFAICT this can go away entirely.
We had problems because we'd call Destroy on a port after calling Destroy on
its streams. This patch makes the port's Destroy ControlMessage not use a stream,
instead we get the stream from the port directly. It also makes us update the
graph's mPortCount only when the port is finally destroyed; this fixes a potential
bug where the current graph could shut down when all streams are removed, before
all ports have been completely destroyed.
--HG--
extra : rebase_source : 3245fa64b79fb8a75c17190f1a4a2af6d42a5012
test_streams_element_capture_reset.html is updated to test that mozCaptureStreamUntilEnded actually stops
capturing when the stream ends. It also tests that seeking and reloading the media resource keep
feeding a mozCaptureStream stream, and feed the right amount of data.
--HG--
extra : rebase_source : 07faf20b8a99b5e7dcdfb27b3a2096fdfd570f45
Moves to a new setup where a decoder manages a single SourceMediaStream internally. Each stream
returned from mozCaptureStream(UntilEnded) is a TrackUnionStream which is fed by the
decoder's SourceMediaStream.
We want the captured streams to be blocked while the media element is not playing. We do that
by blocking any captured stream that has no SourceMediaStream feeding into it, and blocking
any SourceMediaStream while its decoder is not playing.
We arrange for the decoders's PlaybackEnded to be delayed until its SourceMediaStream has
finished according to the media stream graph. This ensures the state of captured media streams
corresponds more closely to the media element state.
--HG--
extra : rebase_source : 3324ff0e9bdce9c71a23c0f5f2032815e9046081
I put this in in bug 778420, but it looks like it wasn't necessary, since the
tests seem to pass without it. It's on the critical path for this longish-running
test, and it also breaks stuff with respect to __exposedProps__. Let's kill it.
On x86_64 Fedora 17, this patch yields an 8ms (1.6%) speedup on SunSpider compared to the tree just prior to the introduction of CallNonGenericMethod, or a ~12ms (2.8%) speedup compared to the tree just after the introduction.
