The IPDL parser handles include statements by using a stack of
parsers. If an inner parser encounters a parsing error, it will print
out an error message, which is maybe okay, but then it makes two
mistakes:
1. It does not pop the current parser off of the parser stack. This
means that the file that included the syntactically invalid file will
be parsed as though it were the invalid file. In bkelly's case, an
.ipdl file included an invalid .ipdlh file, so he got a bizarre error
message about how you can't define a protocol in a header, because the
parser was treating the protocol in the .ipdl file as though it were
in the .ipdlh file. I fixed this by using a "finally" clause to pop
the parser stack, ensuring that it is correct even in case of error.
2. A parse error in the include should cause the entire parse to fail,
but instead it will keep going. inc.tu will get set to None, which
eventually causes an error later in type checking, when it attempts to
examine inc.tu. I fixed this by only catching the parse error where we
invoke the outermost parser. This has the drawback that later errors
in other files will not be reported. An alternate fix would set a
global flag to indicate that a parse error had occured, and somehow
report that to the caller.
I think this bug was introduced in 2009 by commit
cb8189926a69872c73508fba50830f0d07af341f.
MozReview-Commit-ID: DhbDUO7MXGB
--HG--
extra : rebase_source : cee371cd54ebf575f78aa8b2441afbde8b3c2b8f
"For each leaf in the calc() expression, ComputeCalc will call either
ComputeNumber (when the leaf is the left side of a Times_L or the right
side of a Times_R or Divided) or ComputeLeafValue (otherwise)."
A future patch in this series adds support for evaluating pure-integer calc()s.
We rename ComputeNumber to ComputeCoefficient and introduce a coefficient_type
typedef so that coefficients can be integers. We don't want to leave it as
'number' because that is confusing (e.g. CSS <number>s are float values).
We also rename NumbersAlreadyNormalizedCalcOps to
FloatCoeffsAlreadyNormalizedCalcOps, and expect AppendCoefficient in the
template given to SerializeCalc instead of AppendNumber.
This requires some renames in nsCSSValue and nsRuleNode.
I would split this into a separate 'fully-automated' patch, except that it's so
few renames and it feels bad to add the comments separately.
We also have to add |typedef float coeff_type| to two CalcOps implementations
in nsRuleNode because they multiply-inherit from two classes that define
coeff_type as float.
MozReview-Commit-ID: 1ZmBLsGr6hK
--HG--
extra : rebase_source : 219b97c65794c404680a36607506dde66b11e4f4
Enable remote printing for Mac by setting print.print_via_parent=true by default.
MozReview-Commit-ID: DKiMJPiIO0n
--HG--
extra : rebase_source : 1f19477914ab946a099c238b06a34fa84c8952c5
NS_LogCOMPtrAddRef and NS_LogCOMPtrRelease always pass false to
GetSerialNumber, because they pass in everything they get without
regard to whether it is being logged or not, so they don't want to
create a serial number if none exists. This causes the assertions
added in bug 1309051 to be hit. To work around this, I hoist the
assertion into the other callers of this method. Two of them already
had this check, but it was non-fatal.
This also makes the asserts not happen in release builds, as I decided
it doesn't really matter what happens if somebody tries to use it
there.
--HG--
extra : rebase_source : 5e70290492fd442b79b4d40c300a263e322f485b
Update the test to avoid closing / reopening the toolbox each time a new color
is tested. An element is created upfront for each color to test, and the test
simply selects a different node when switching to a different color.
MozReview-Commit-ID: Atz70fwoMN2
--HG--
extra : rebase_source : aba56bef09c05e94b55ce2153d48b502f586e3c5
PluginContent listens for a particular type of Decoder Doctor notification.
Specifically, it listens for ones of type "cannot-play" for mimetypes that
include "application/x-mpegurl". If PluginContent sees that notification,
and we've already shown the Click-to-Play notification, then what we're
dealing with is web content that is probably using Flash to decode an
HLS feed. Because we don't want to spring up the Click-to-Play
PopupNotification on a Decoder Doctor notification (which might happen
at any time), we show the Hidden Plugin notification bar instead
to alert the user that they might need to enable Flash to view the
HLS feed.
MozReview-Commit-ID: IUFqhbhh0Sc
--HG--
extra : rebase_source : 4c656217c296e5ae5fb425e864192461e0daefa0