This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
`*Inlines.h` shouldn't be included by another header file, but `nsPresContext.h`
does it. This causes include-hell which blocks the following fix.
Additionally, it causes an include hell between `PresShell.h` vs.
`nsIPresShell.h` and `nsPresContext.h if `Document.h` includes `PresShell.h`.
Therefore, this patch also solves this include hell with adding
`nsPresContextInlines.h`.
Differential Revision: https://phabricator.services.mozilla.com/D25333
--HG--
extra : moz-landing-system : lando
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
--HG--
extra : moz-landing-system : lando
Update the vendored Fluent libraries to their latest versions, both supporting Fluent Syntax 0.9.
Differential Revision: https://phabricator.services.mozilla.com/D25043
--HG--
extra : moz-landing-system : lando
Moved tab context menu out of browser.dtd to browser.xul except for sendPageToDevice, sendLinkToDevice, moveTabOptions, moveSelectedTabOptions, undoCloseTab. Not sure if tabbrowser.js and tabbrowser.xul are working as intended.
Differential Revision: https://phabricator.services.mozilla.com/D19312
--HG--
extra : moz-landing-system : lando
Bug 1416015 and Bug 1470348 added function calls for CompositorOGL. Similar things needs to be done for RenderCompositorEGL.
Differential Revision: https://phabricator.services.mozilla.com/D25199
--HG--
extra : moz-landing-system : lando
A spatial id of 0 refers to the root reference frame on the WR side, but
we shouldn't be using that on the Gecko side at all. Due to the
early-exit codepath in ClipManager we were actually sending some display
items with this spatial id over to WebRender. Although this doesn't
appear to cause any user-visible problems it seems wrong and can confuse
debugging other issues.
Differential Revision: https://phabricator.services.mozilla.com/D25296
--HG--
extra : moz-landing-system : lando
If there's at least 2 content blocking messages displayed
for a given page navigation, we display a warning group
containing the messages, collapsed by default.
This means we need to move or insert those warning messages
at the right position in visibleMessages, either when they're
added, or when we expand a group.
Two mochitest are added to make sure this works as expected,
one for generic warningGroup features (expanding, group per
navigation session, …), and another one specifically for
content blocking warning group, where we check that every
type of content blocking message can be grouped.
The grouping won't occur unless the groupWarnings preferences
is on.
Differential Revision: https://phabricator.services.mozilla.com/D23552
--HG--
extra : moz-landing-system : lando
This component will be used to render warning groups messages.
We also add a `inWarningGroup` prop to the `Message` component
so warnings that will be displayed in such warningGroup can
be styled differently (no warning icon, a different color for
the indent).
Add some utils functions and constants to check if a message
should be a warning group.
Differential Revision: https://phabricator.services.mozilla.com/D23551
--HG--
extra : moz-landing-system : lando
This will be used to enable groups of warning messages (Tracking Protection,
CSP, CORS, …).
Differential Revision: https://phabricator.services.mozilla.com/D23550
--HG--
extra : moz-landing-system : lando
Not specifying an explicit host causes pywebsocket to listen on the
default address, which may be 0.0.0.0. This triggers the firewall
on macOS, and causes the following prompt to be shown when mochitests
are run:
> Do you want the application "Python.app"
> to accept incoming network connections?
The dialog is a nuisance because it is always on top. Since denying
the access does not change the outcome of tests, it should be safe
to only listen on localhost.
Differential Revision: https://phabricator.services.mozilla.com/D25364
--HG--
extra : moz-landing-system : lando
This autofill popover was being displayed in the incorrect place because the display rect we were providing to the `AutofillManager` was the rect for the `GeckoView` and not the rect for the HTML element that the autofill popover was relating to.
1. Add view dimensions to info passed to autofill in `GeckoViewAutoFill`.
2. Use those view dimensions to calculate the correct location on the screen using `pageToScreenMatrix` in `GeckoSession`.
The resulting locations were incorrect, as the values used by `pageToScreenMatrix` were out of date. The `GeckoSession` was only notified about updated metrics during first composite, which meant that when the metrics changed during zoom and scroll on soft keyboard presentation, `GeckoSession` was unaware of it.
3. Update `GeckoSession` with new screen metrics when they change and not only during first composite.
Despite this change ensuring that `GeckoSession` always had the correct values for the viewport size and location, the request to provide the autofill location was made before the zoom and scroll was complete, meaning that even then out of date values were used during the calculation. The intial solution was to fire an event once zoom was complete, but despite this event being fired after the new screen size had been calculcated in `AsyncCompositionManager`, `GeckoSession` did not receive the values until after the event had been processed (the calls were out by 0.024ms).
5. Call new method `onScreenMetricsUpdated` inside `SessionTextInput` after screen metrics have been updated. Call `AutofillManager#notifyViewEntered` from this function.
This was not my preferred solution to this, but timing issues meant I could not find/think of an alternative way of delaying the calculation of the autofill popover location until after `GeckoSession` had been updated.
This patch currently fixes things on GV apps. Occasionally, on Fennec, the autofill view is out of alignment slightly. This needs further work.
Differential Revision: https://phabricator.services.mozilla.com/D24397
--HG--
extra : moz-landing-system : lando
While running presets + intersection queries works with 'mach try fuzzy
--preset <foo>', it is still broken with 'mach try --preset <foo>'.
Differential Revision: https://phabricator.services.mozilla.com/D25298
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
`*Inlines.h` shouldn't be included by another header file, but `nsPresContext.h`
does it. This causes include-hell which blocks the following fix.
Additionally, it causes an include hell between `PresShell.h` vs.
`nsIPresShell.h` and `nsPresContext.h if `Document.h` includes `PresShell.h`.
Therefore, this patch also solves this include hell with adding
`nsPresContextInlines.h`.
Differential Revision: https://phabricator.services.mozilla.com/D25333
--HG--
extra : moz-landing-system : lando
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
--HG--
extra : moz-landing-system : lando
They're only used in forms.css, and only for some anonymous content, which are
not content-accessible in the first place.
The only place where this could be exposed is calling
getComputedStyle(input, "::placeholder"), so I think this should be pretty safe,
but I've added a pref just in case.
While at it, also derive the Parse implementation. Less code is better.
Differential Revision: https://phabricator.services.mozilla.com/D25118
--HG--
extra : moz-landing-system : lando
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--HG--
extra : moz-landing-system : lando
nsContentSink used to decide that it was fine to not notify of silent appends to
a document from the parser if the node was not on our document already.
That's not ok, since if styling or layout have happened already on the document
we're getting inserted into nobody notices them, which is wrong.
Differential Revision: https://phabricator.services.mozilla.com/D25300
--HG--
extra : moz-landing-system : lando
No one (m-c, c-c and bluegriffon) uses nsIPlaintextEditor.setWrapColumn from
script. It is used from C++ only.
Differential Revision: https://phabricator.services.mozilla.com/D25363
--HG--
extra : moz-landing-system : lando
This ensures the JS shell and browser behave the same way and it's nice for fuzzing.
Differential Revision: https://phabricator.services.mozilla.com/D25204
--HG--
extra : moz-landing-system : lando
