Bug 1241917 made it so that a subframe's displayport base is restricted
to the root composition bounds (in addition to its previous
restrictions). This involved an expensive coordinate transformation
causing a scrolling performance regression.
This avoids restricting the displayport base to the root composition
bounds unless the frame has a display port, avoiding the expensive
computation unless necessary.
MozReview-Commit-ID: FVacUscAfu2
--HG--
extra : transplant_source : %F9%E9%19%06/%9C%EA%8C%D1%D5%BD%ED%26C%97y%15%92%7E%CB
Mostly just declaring globals that Cu.imports defines but there are some actual
bugs here that have been fixed as well as one test that just never ran because
of a hidden exception.
MozReview-Commit-ID: J6uIpYp8ANx
--HG--
extra : rebase_source : 5c19b92e4242088b6fc7a268f255fe9a795928f6
extra : source : 3e5b6df276a9a20fe7b3655656e62a09bc46aaa9
xpcshell tests used to use head_*.js files so this adds those for global
discovery.
MozReview-Commit-ID: BOsoGIpwdgu
--HG--
extra : rebase_source : ef36531641cbd353625019f8deba333cfd352891
extra : source : 70eca07367f40a9b4fe8c6e23ec0aef73bf2a962
This defines a few additional globals but also turns on the browser environment
for everything in browser and toolkit. This may lead to some false negatives
but we have lots of code that runs in a browser context so in the name of
getting rules turned on I think this is a useful step.
MozReview-Commit-ID: BdWouZGK6d
--HG--
extra : rebase_source : a88116d149af76aa35ee0757b3b51b6f97646ebe
extra : source : 04c1740aa49904a56bd662ee0c8aed69e6f99f8b
This adds more of the scripts that browser.js relies on and also makes
browser-chrome head files import the browser.js globals.
The MOZ_JSDOWNLOADS block in contentAreaUtils only seems to hide a single
function, I don't see any need to keep hiding that now we're on by default.
MozReview-Commit-ID: 5zvF3JtJrZG
--HG--
extra : rebase_source : 94daff602b51d7ad57a24872d9eba9b304cf2da9
extra : source : b554c7ce41c42f16c2279ae88fd9567da7509bff
To properly lint XBL files we need to support things like import-globals-from
and other ESlint comment directives so we have to pass comments through to the
code blocks that ESlint parses. Unfortunately the way the XBL processor works
now is by passing a separate code block for every method/property/etc. in the
XBL and ESlint doesn't retain state across the blocks so we would have to prefix
every block with every comment. Instead this change makes us output just a
single block that roughly looks like this:
<comments>
var bindings = {
"<binding-id>": {
<binding-part-name>: function() { ... }
}
}
This has some interesting bonuses. Defining the same ID twice will cause a lint
failure. Same for the same field in a binding. The line mapping is a little
harder and there are still a few lines that won't map directly back to the
original file but they should be rare cases. The only downside is that since
some bindings have the same binding declared differently for different platforms
we have to exclude those from linting for now.
MozReview-Commit-ID: CAsPt5dtf6T
--HG--
extra : rebase_source : 91a60ef0359ef53093fe197ed63dbc4e1a9f10a5
extra : source : 01675e4828b524c04a9057d68b41e9cc01ca1bb9
While working on turning on no-undef I discovered that the various rules we
have for defining globals are a little inconsistent in whether the files they
load recurse through import-globals-from directives and none of them imported
eslint globals directives.
I think we're better off putting all this global parsing code in a single place
rather than spread across multiple rules. Have one rule to turn it on for
parsed files and one function to load globals from other files and make them
share most of the code so we won't get inconsistent. If we find us needing to
turn on/off individual features we can figure out a way to do that in the
future.
This patch does that, the globals.js file does all global parsing with a shared
object that receives events from the AST, either through from an ESlint rule
or from a simple AST walker using estraverse.
MozReview-Commit-ID: 9KQZwsNNOUl
--HG--
extra : rebase_source : 0f1cceca29ac398be97a55bbcd09fe58a8be1435
extra : source : 878db4caf845282f06542793bc4b5c24fa658c14
After calling FlushLayout(), PresShell::Destroy() might be called and we
should consider PresShell and other resources will be no longer valid.
Before this patch, AccessibleCaretManager and AccessibleCaret(s) are
deallocated in PresShell::Destroy(). However FlushLayout() are all
invoked in AccessibleCaretManager, we need to keep manager alive to
clean up after PresShell::Destroy().
This patch makes AccessibleCaretManager live after PresShell::Destroy(),
and use IsTerminated() to check whether PreShell is vaild after each
FlushLayout() calls.
Note that event though AccessibleCaretEventHub will be unref in
PresShell::Destroy(), all the callers to AccessibleCaretEventHub's
public methods already add a ref to AccessibleCaretEventHub. So we don't
need to worry about AccessibleCaretEventHub and AccessibleCaretManager
die immediately after PresShell::Destroy().
MozReview-Commit-ID: DDpXZ7v3zyo
--HG--
extra : rebase_source : 2698f0313e394b64ff8caacf21493c874510a7ce
Fennec enables sCaretsExtendedVisibility which uses
Appearance::NormalNotShown instead of Appearance::None to keep actionbar
shown during scrolling. This breaks selection mode update when the
positions of the carets are not changed after scrolling.
To fix this, we need to implement appearance recovering for selection
mode scrolling like we did for cursor mode in bug 1212732, and make
UpdateCaretsForSelectionMode() respects UpdateCaretsHint.
MozReview-Commit-ID: LkfUIGKHL0h
--HG--
extra : rebase_source : 2e68786e09046967f7c6af16fa6b393f133dc12c