In our previous code, we would accidentially not perform the correct
security checks when retreiving data from DataTransferItems in some
situations. The regressing patch fixed this behavior and ensured that we
always perform the correct security checks, making any "insecure"
accesses (such as accesses to file data from the OS in DragEnter) would
raise an NS_ERROR_DOM_SECURTY_ERROR. This behavior is not consistent
with Chrome, and thus OneDrive would accidentally trigger an exception
and break its d&d handling logic.
With this patch our behavior for "insecure" accesses to file data from
the OS is more in line with Chrome's, in that we now don't raise an
exception, but instead just produce the value "null" when the data
should not be avaliable yet. From my quick test this fixes the problem
with OneDrive, and should be a fairly trivial patch to uplift to Beta,
with very little risk.
This patch doesn't include a test, as Drag and Drop is a very difficult
component to test in automation, however I am currently working on
defining a set of manual tests for the Drag and Drop component, and I'll
make sure that our behavior for "insecure" accesses is tested in those
tests in the future.
MozReview-Commit-ID: 4pnPyL1tgcV
The idea is to not make consumers think about whether the principal exists or
not when the caller knows for sure that it does.
The substantive changes are in dom/bindings, nsHTMLDocument::SetDesignMode, and
around the CanUseStorage bits. Everything else is pretty mechanical.
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
