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
Pings are sent in the implementations of the nsISelectionController methods
ScrollLine, ScrollPage, ScrollCharacter, and CompleteScroll. It is assumed
that these methods are triggered by keyboard input.
A small number of false positives can occur if these methods are called
in response to something other than keyboard input; this is considered
acceptable.
--HG--
extra : commitid : JDXW8ptuXkF
extra : rebase_source : c45fe2b16484ad370edb852d8eafbc76ca7d0bac
extra : amend_source : b4af21228768221211a42c11a2ff306a6f2bb402
extra : histedit_source : 7cdc4b4df3579682fad194ddfc04c7a5d02c0d3e
Add helper function nsIFrame::In3DContextAndBackfaceIsHidden() which
checks both if a frame is backface-hidden and whether it is within a
3D-transform context.
In FrameLayerBuilder, check this function rather than BackfaceIsHidden()
to determine whether a frame needs a backface-hidden layer. This will
avoid creating unnecessary extra layers for non-3d-transformed items
which for some reason have backface-hidden set.
On Fennec, it's possible that after automatically zooming an editable
input, the mImaginaryCaretRect for the caret remains the same. Only the
zoom level is changed. Therefore, the zoom level should also be
considered to determine whether the position is changed or not so that
the caret can get updated.
MozReview-Commit-ID: CrictS4S0Yl
--HG--
extra : rebase_source : f26f89cb72a9ae8a55104054121486a67e841513
It's not obvious that it does this (unless you read the comment or the code), and we don't gain much by doing it.
Also we need to split it up for the next patch in this bug.
CLOSED TREE
Backed out changeset dbadb8fe5803 (bug 1216001)
Backed out changeset a30593ebd58e (bug 1216001)
Backed out changeset c1646ffa71b4 (bug 1216001)
To retain backward compatibility, <details> tags should not collapse its
children when dom.details_element.enabled = false.
--HG--
extra : rebase_source : 6b47e64672720ffecd23f670c31de1c7d92bee8c
This is a regression by "Bug 1121468 - Go to NoActionState after
receiving release on LongTapState."
When receiving a scroll event in LongTapState, i.e. apz starts, we
should call OnScrollStart() and move to the ScrollState.
--HG--
extra : commitid : GsQNnTtqhzh
extra : rebase_source : 0a6ad44a4bf97ed15b374094929df5409deeba41
Without this patch, patch 2 will cause assertions since
nsFrame::DestroyFrom calls nsFrame::HasCSSAnimations (at a time when the
child frame has been destroyed), which calls into the code modified in
patch 2 to call GetStyleFrame.
--HG--
extra : commitid : EkhtcNIf7ye
When double-clicking on a default anonymous <summary> element, the first
eMouseClick will make the summary element being removed from the
document. This generates an assert in
PresShell::HandleEventWithTarget().
To prevent this assert, ensure the mouseContent is in document before
dispatching the eMouseDoubleClick event.
Since GetCrossShadowCurrentDoc() was deprecated, replace it with
GetComposedDoc().
--HG--
extra : commitid : K9pCdof8z3f
extra : rebase_source : 3adfdb9938de30fd0ca365168c33dcdcef8ca285
This restores the quirky behavior for text inputs, which was removed by
patch 2, but only halfway (for width but not max-width), which matches
Chromium and Edge.
--HG--
extra : commitid : 7uk3XdYc1LC
This just reorders the if-else chain to change which conditions are
tested first. Prior to patch 1, the order didn't matter, but with patch
1, the order does matter, and the order that we happened to have was the
opposite of the one that matches Chromium and Edge.
--HG--
extra : commitid : 6sFft3gnM2g
This reduces the set of elements to which this quirky behavior applies.
This matches the behavior of Chromium and Edge.
--HG--
extra : commitid : 9qz7ODJhNzS
This (modulo changes in later patches) matches the behavior of Chromium
and Edge. It increases the set of elements to which this quirky
behavior applies.
--HG--
extra : commitid : 4nWEgnUB0rt
Per request in bug 1240917 comment 15, we decided not to show caret when
single press on an empty input. This effectively reverts the work in Bug
1230582.
--HG--
extra : commitid : IjKGpqAR6zP
extra : rebase_source : d476618b4f419cf2d96bb33264cfd8ccb6e3fa61
