We can't guarantee any data will be written, it should suffice to just
make sure that the socket closes immediately and then verify that
a complete set of data wasn't read.
MozReview-Commit-ID: CHHuJEGRVgX
--HG--
extra : rebase_source : 2269b73a4497011c9604628710055a0fc08e0470
eQueryTextRect is used by widget and eQueryTextRectArray is used by ContentCacheInChild. So, matching their result guarantees that widget can get same result both in non-e10s mode and e10s mode. So, the matching should be tested.
MozReview-Commit-ID: 6GfbyvZ9X7H
--HG--
extra : rebase_source : 12511d84cbd94b3f4edf42367a84ee45abc66d9e
Currently, ContentEventHandler::OnQueryTextRectArray() is used only in e10s mode (at caching necessary character rects in ContentCacheInChild). Therefore, this bug occurs only in e10s mode.
ContentEventHandler::OnQueryTextRectArray() applies CSS transform only to each frame rect. Therefore, character rect's width and height are not applied.
This patch makes the loop apply CSS transform to each character or line breaker rect (i.e., each item of charRects). Then, we need to rewrite the lastCharRect hack. It stores the last charRect value for computing next line breaker rect if next line breaker is caused by a block level element or something, i.e., not caused by a <br> frame. So, when brRect is computed with lastCharRect, the loop needs to apply CSS transform of the last text frame to the following brRect because it tries to compute a caret rect immediately after the last character. For doing this, this patch adds lastFrame which stores the last frame for lastCharRect and set it to baseFrame. Then, at applying CSS transform to each charRect, it can apply CSS transform of expected frame.
Similarly, when brRect is computed with last text frame, this patch looks for the last text frame from lastTextContent and use it as base frame to apply to CSS transform.
MozReview-Commit-ID: 5Yr2HMrooHd
--HG--
extra : rebase_source : fa643f442036d9167a1df3a4383b0802a1729a3e
This is to work around an issue where the call to CoInitializeSecurity in MainThreadRuntime::InitializeSecurity causes the impersonation token, used to give the pre-lockdown permissions, to be replaced with one with no rights.
This only seems to happen when the lockdown token is USER_NON_ADMIN, which is not a restricted token.
MozReview-Commit-ID: 6HFuDFmWLTf
This avoids printing harmless (but confusing) errors to the log. For instance, git users
will see a '.hg not found!' error in the output even though not finding an hg repo is
expected in that case.
MozReview-Commit-ID: DBPOabcV7PA
--HG--
extra : rebase_source : a40de185cd4bf0c58917065d1331e0e663b92b94
