Long-pressing on a text in an unfocused iframe to select a word never
works. Currently, you need to single tap to focus the iframe first.
Each PresShell has an associated AccessibleCaretEventHub. This patch
fixes this bug by routing the event to the AccessibleCaretEventHub under
the event point, and handle it there. If the event is not handled, then
we handle it by the focused AccessibleCaretEventHub as before.
I've experimented with only routing the event to the
AccessibleCaretEventHub under the event point, without routing to the
fallback focused AccessibleCaretEventHub. However, caret dragging didn't
work in iframes. I didn't debug further.
Differential Revision: https://phabricator.services.mozilla.com/D52767
--HG--
extra : moz-landing-system : lando
While it calls `RestyleManager::ContentStateChanged()`, it blocks script
with `nsAutoCauseReflowNotifier`. Therefore, it should be marked as
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` at least (looks like the other override,
`DocAccessible::ContentStateChanged()` does not run script).
There is a concern about the lifetime of `RestyleManager`. It's destroyed
when `nsPresContext::DetachPresShell()` is called. It's called by
`PresShell::Destroy()` and destructor of `nsPresContext`. The latter is
safe since `PresShell` owns `mPresContext` and it's never cleared. However,
I'm not sure about the former. It might be better to create blocker of
synchronous handling of `PresShell::Destroy()`.
And also this does not make `Document::ContentStateChanged()` use
`RefPtr<PresShell>` at calling it because it might cause performance
regression, but it does not do anything after destroying
`nsAutoCauseReflowNotifier`.
Finally, for guaranteeing that the lifetime of `PresShell::mPresContext` is
longer than `PresShell`, this makes it to `RefPtr<nsPresContext> const`.
However, initializing it in constructor breaks other objects' initialization
process since they assume that `PresShell::GetPresContext()` won't return
valid pointer until the `nsPresContext` is attached. For solving this issue
safe, this patch keeps setting `mPresContext` in `Init()` with `const_cast`
hack.
Differential Revision: https://phabricator.services.mozilla.com/D55804
--HG--
extra : moz-landing-system : lando
It calls `Document::FlushPendingNotification()` so that we should mark it
as `MOZ_CAN_RUN_SCRIPT`.
And the method calls it of `mDocument` and `mDocument` is never modified
after it's initialized. Therefore, we can move the initializer to the
constructor and make `RefPtr<Document>` to `RefPtr<Document> const`. Thus,
we can avoid unnecessary auto `RefPtr`.
Differential Revision: https://phabricator.services.mozilla.com/D55803
--HG--
extra : moz-landing-system : lando
It dispatches a DOM event so that it should be marked as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D55801
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
On Chrome, visual viewport resize event is fired repeatedly during dynamic
toolbar transitions and visual viewport height obtained by the VisualViewport
API is also changed, but in terms of layout the height value is never used
until the dynamic toolbar height reaches to zero or is changed from zero.
The height used at the time is the height for vh units when the toolbar height
reaches to zero and the ICB height when the toolbar height is changed from zero.
To do so, we need to have another visual viewport size in parallel to the
original one and use them depending on situations.
Differential Revision: https://phabricator.services.mozilla.com/D52338
--HG--
extra : moz-landing-system : lando
In particular, not let ResizeReflow take the old and new size. Most of the
callers pass dummy values anyway.
Instead, use the old size of the layout viewport. This ensures we fire resize
events only if the layout viewport actually changes.
This is important because the first resize of the mobile viewport manager
after a navigation has an "old size" of 0x0, even though the layout viewport
is initialized on presshell initialization to the right size.
Thus, we fire resize events unnecessarily in that case, which is the root cause
for bug 1528052.
To do this, we need to shuffle a bit of code in nsDocumentViewer that deals with
delayed resizes, to set the visible area _and_ invalidate layout, rather than
setting the visible area and _then_ relying on doing a resize reflow.
Further cleanup is possible, though not required for my android resizing fix, so
will do separately.
Differential Revision: https://phabricator.services.mozilla.com/D46944
--HG--
extra : moz-landing-system : lando
This is much easier than the existing ResizeReflowIgnoreOverride function, and
this will allow me to avoid flushing if needed (we already kinda do that
already with the "suppressResizeReflow" thing), which in turn allows me to
consolidate a bunch of the logic for resizes.
The function should be much easier to follow:
* Set the new viewport (async, doesn't do any work).
* Invalidate layout as needed due to the viewport change (that is, resize hint
for the root frame, and invalidate isizes if needed). Also async and doesn't
do any reflowing itself.
* Flush layout / do the reflowing all at once. I think we can stop doing this
much more often now, but that's follow-up work.
Depends on D43798
Differential Revision: https://phabricator.services.mozilla.com/D43799
--HG--
extra : moz-landing-system : lando
Collect telemetry for the number of pending style and layout flush requests per
flush and the number of style and layout flushes per nsRefreshDriver::Tick. A
style flush reports only style requests, but a layout flush reports style and
layout requests since flushing layout implies a style flush also.
Differential Revision: https://phabricator.services.mozilla.com/D40756
--HG--
extra : moz-landing-system : lando
nsTypeAheadFind.cpp contains all of the callsites to this function, so it seems like a logical place for it to live.
Differential Revision: https://phabricator.services.mozilla.com/D40696
--HG--
extra : moz-landing-system : lando
I missed in bug 1487216 that the pres arena memory reporting assumes that the
entry indices are frame class ids, which means that we're reporting some display
list arena entries as frames, which is obviously wrong.
Cleanup a bit nsPresArena to remove the custom id concept, and report also
individual display item type memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D35368
--HG--
extra : moz-landing-system : lando
With desktop zooming, we need to separate the concepts of "may have a distinct
visual viewport" from "has mobile viewport sizing logic applied to it".
This can be thought of as completing the disentanglement of zooming from meta
viewport support started in bug 1459260.
Differential Revision: https://phabricator.services.mozilla.com/D32770
--HG--
extra : moz-landing-system : lando
Unfortunately, `EventChainVisitor` does not grab the `nsPresContext` with
`RefPtr` by itself. Therefore, there is no guarantee of the lifetime without
checking the origin when its subclasses are instantiated. This patch changes
it and subclasses to `MOZ_STACK_CLASS` since only `EventDispatcher::Dispatch()`
creates them in the stack with given `nsPresContext`. Additionally, it's
already been marked as MOZ_CAN_RUN_SCRIPT_BOUNDARY`. Therefore, the
`nsPresContext` instance has already been guaranteed its lifetime by the
caller. For making this fact stronger, this patch marks their constructors
as `MOZ_CAN_RUN_SCRIPT`. Therefore, nobody can create those instances without
guaranteeing the lifetime of `nsPresContext` and `dom::Event`. Note that
it may look like that `mPresContext` of `EventChainPostVisitor` is not
guaranteed. However, `EventChainPreVisitor` which gives `nsPresContext` to it
is also a stack only class. So, it won't be deleted before
`EventChainPostVisitor` instance.
Differential Revision: https://phabricator.services.mozilla.com/D30010
--HG--
extra : moz-landing-system : lando
Additionally, this sorts out the order of member variables for minimizing the
instance size.
And also this changes `enum RenderFlags` to `enum class RenderingStateFlags`.
Differential Revision: https://phabricator.services.mozilla.com/D29312
--HG--
extra : moz-landing-system : lando
This patch makes widget use `mozilla::PresShell` directly rather than via
`nsIPresShell` and changes some pure virtual methods of `nsIPresShell` which
called by widget to `mozilla::PresShell`'s non-virtual methods.
Differential Revision: https://phabricator.services.mozilla.com/D29112
--HG--
extra : moz-landing-system : lando
And also this patch moves some related methods which use the inline methods
and member variables used only by them.
Differential Revision: https://phabricator.services.mozilla.com/D29201
--HG--
rename : layout/base/nsIPresShellInlines.h => layout/base/PresShellInlines.h
extra : moz-landing-system : lando
There is the following usage of nsIPresShell:
```
nsCOMPtr<nsIPresShell> presShell = do_QueryReferent(mPresShellWeak);
```
So, for changing this to:
```
RefPtr<PresShell> presShell = do_QueryReferent(mPresShellWeak);
```
PresShell should have its own IID.
Differential Revision: https://phabricator.services.mozilla.com/D29197
--HG--
extra : moz-landing-system : lando
`CapturingContentInfo` struct is used only in `PresShell.cpp` so that we can
make it a private struct of `PresShell` if we move all users of them,
i.e., API to access them, from `nsIPresShell` to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D29111
--HG--
extra : moz-landing-system : lando
The fixes a latent bug with WebRender where we would clear it after reading it
in ComputeScrollMetadata, but WR would sometimes call ComputeScrollMetadata a
second time for the same scroll frame in the same transaction, resulting in
the update sometimes not making it into the transaction.
Differential Revision: https://phabricator.services.mozilla.com/D28776
--HG--
extra : moz-landing-system : lando
This patch moves remaining public `enum` of `nsIPresShell` to `mozilla`
namespace in `mozilla/PresShellForwards.h` and make them `enum class`es.
Additionally, some methods which use the moving `enum`s from `nsIPresShell`
to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D28607
--HG--
extra : moz-landing-system : lando
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
This patch creates new header, `mozilla/PresShellForwards.h`. It should have
all forward declarations of global class/struct in `nsIPresShell.h` and
`mozilla/PresShell.h`.
Additionally, this moves all `enum`s and `constant`s in them into the new file
with changing them to `enum class`es.
This will make other headers which require only specific types in the header
files not include them.
Differential Revision: https://phabricator.services.mozilla.com/D28605
--HG--
extra : moz-landing-system : lando
Now, we can mark `DoScrollContentIntoView()` as `MOZ_CAN_RUN_SCRIPT` and move
it from `nsIPresShell` to `PresShell` with a member.
Differential Revision: https://phabricator.services.mozilla.com/D28321
--HG--
extra : moz-landing-system : lando
This patch marks `ScrollContentIntoView()` as `MOZ_CAN_RUN_SCRIPT` and changing
some callers of them to guarantee thar their parent callers are also safe.
Additionally, this patch moves it from `nsIPresShell` to `PresShell` because
all callers can refer `PresShell` directly.
Unfortunately, this patch changes a lot of methods in autocomplete and satchel
since this patch needs to mark some interface methods as `can_run_script` and
they are called each other. This means that autocomplete module is really
sensitive like editor module. Perhaps, autocomplete and satchel should do
scroll asynchronously and unmark some of them as `MOZ_CAN_RUN_SCRIPT` again.
Differential Revision: https://phabricator.services.mozilla.com/D28320
--HG--
extra : moz-landing-system : lando
Next, we should mark `PresShell::ScrollContentIntoView()` as
`MOZ_CAN_RUN_SCRIPT` because it's used widely.
This patch marks its `PresShell` users, `GoToAnchor()` and `ScrollToAnchor()`,
as `MOZ_CAN_RUN_SCRIPT`. Additionally, this patch moves them from
`nsIPresShell` to `PresShell` because all callers refers `PresShell` directly.
Differential Revision: https://phabricator.services.mozilla.com/D28319
--HG--
extra : moz-landing-system : lando
Noemi Erli
Ting-Yu Lin
Sebastian Streich
Emilio Cobos Álvarez
Gurzau Raul
Masayuki Nakano
Gabriele Svelto
Hiroyuki Ikezoe
Dan Glastonbury
Sylvestre Ledru
Botond Ballo
Miko Mynttinen
Jonathan Watt
Ehsan Akhgari
Edgar Chen
Hiroyuki Ikezoe