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
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
The main motivation of this patch is to fix the prefixed function name
used in one string. But updated string should have different a different
identifier, otherwise it might be ignored. Since we should eventually
prefer using word "fullscreen" over "full-screen", it is easier to just
change all of them together.
This method actually never throws. IsFullScreenDoc() simply checks
whether GetFullScreenElement() returns nullptr, which means if that
method returns true, the "!el" check would never fail.
Adds --require-buildprops option used by the standalone builder. When this option is
specified, a partner property must be present in the buildprops.json file. This limits
the repack operation to that single partner.
One can run individual tests with python testfile.py Class.method. But
the output for tests only shows the method so looking at a test output
is not enough to tell how to run one particular test. Moreover, there
are many cases where a test file contains multiple classes, and we fail
to identify the difference between those classes.
Python's unittest has decorators to mark tests as skipped or expecting
to fail. Mozunit runner fails to print anything for them.
While here, somehow unify the output for TEST-UNEXPECTED-FAIL.
This leaves known failures silent about the failure. It would be better
to only show them with a flag, like -v, and to leave it to a followup.
Python's unittest separates errors and failures, where the former is
uncaught exceptions and the latter uncaught assertions. We were only
printing the former, making the mozunit runner output useless to debug
failures due to assertions in the code being tested.
I would usually edit the test to temporarily switch to unittest.main().
Enough is enough, handle failures properly.
At the same time, instead of printing all the errors one after the other
at the end, print them right after the TEST-UNEXPECTED-FAIL message.
