I talked about this with bz. The issue is that we have a lot of XUL reftests
that end up getting run as remote XUL given that the reftest harness loads
them with file:// URIs. But realistically most of them probably want to test
the fully-featured XBL environment that we provide to frontend and extensions.
So the compromise here is to do XBL scopes for content, and no XBL scopes
for reftests/crashtests.
This crashtest fails because it's running in the remote XUL configuration, in
which we don't have SOWs. In that case, it's no longer interesting to make
the browser assert. ;-)
There are a couple of tests here that do funny things with fields. Our basic
position here is that fields have no place for in-content XBL bindings, but
there's still value in testing this stuff given our heavy usage of XBL in
chrome code. They really should be converted to chrome tests, but I was having
trouble doing that, so I decided to convert them to run without XBL scopes, like
we do for remote XUL.
As a nice side effect, this gives us a tiny bit more test coverage for the
remote XUL configuration.
--HG--
rename : content/xbl/test/test_bug372769.xhtml => content/xbl/test/file_bug372769.xhtml
rename : content/xbl/test/test_bug397934.xhtml => content/xbl/test/file_bug397934.xhtml
According to HFP spec, when we receive AT command 'AT+BLDN', we shall respond
with:
1. 'OK' if the call history is not empty. An outgoing call would be made
2. 'ERROR' if the call history is empty. No call would be made.
However, with current implementation, we are unable to know whether the call
history is empty or not in Gecko. Therefore I introduce a solution, using a task
and a flag to decide if a call is made after AT+BLDN is received, which may not
be perfect but reliable, easy to understand and easy to implement.
ShadowImageLayerOGL::RenderLayer used to call gl()->GetSharedHandleDetails()
directly and uses that result.
This makes us do something similar. As a concequence we also drop the
mTextureTransform member because we are not caching it anymore.
I do wonder if it would make more sense for the content thread to send
the transform along with the update to make sure that it always matches.
This would also make it so that we have no chance of causing a GC
in the compositor to get the transform by calling through java.
