- scroll-behavior-8.html - Tests if dynamically changing the scroll-behavior
css property on a div element takes effect after the page has been painted and
reflowed.
- scroll-behavior-9.html - Tests if dynamically changing the scroll-behavior
on the body element takes effect after the page has been painted and
reflowed.
- When the scroll-behavior CSS value changed, the nsChangeHint_NeutralChange
hint was returned by nsStyleDisplay::CalcDifference. It now returns
nsChangeHint_ReconstructFrame to ensure that the change takes effect.
- When scroll-behavior is changed, the nsChangeHint_NeutralChange was not
sufficient to enter nsCSSFrameConstructor::PropagateScrollToViewport. By
using the same hint as used when the overflow css property changes,
nsChangeHint_ReconstructFrame, PropagateScrollToViewport will be called.
- The scroll-behavior css property is not expected to change often (the
CSSOM-View DOM methods are likely to be used in those cases); however, if
this does become common perhaps a faster-path might be worth while.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
The logcat format used by tbpl jobs in some (maybe all) cases now has a
timestamp and other decorations at the beginning of the line. The regex that
was previously added to filter out reftest failure lines duplicated in logcat
no longer matches the lines correctly; this makes the regex more generic so that
the filtering works again.
- scroll-behavior-8.html - Tests if dynamically changing the scroll-behavior
css property on a div element takes effect after the page has been painted and
reflowed.
- scroll-behavior-9.html - Tests if dynamically changing the scroll-behavior
on the body element takes effect after the page has been painted and
reflowed.
- When the scroll-behavior CSS value changed, the nsChangeHint_NeutralChange
hint was returned by nsStyleDisplay::CalcDifference. It now returns
nsChangeHint_ReconstructFrame to ensure that the change takes effect.
- When scroll-behavior is changed, the nsChangeHint_NeutralChange was not
sufficient to enter nsCSSFrameConstructor::PropagateScrollToViewport. By
using the same hint as used when the overflow css property changes,
nsChangeHint_ReconstructFrame, PropagateScrollToViewport will be called.
- The scroll-behavior css property is not expected to change often (the
CSSOM-View DOM methods are likely to be used in those cases); however, if
this does become common perhaps a faster-path might be worth while.
These tests all involving focusing on an empty element. Touch caret will
not show under the new touch caret UI spec. Therefore, I fix them by
disabling touch caret when running those tests.
We want HasNonEmptyTextContent() to descend recursively into editingHost
since <div contenteditable="true"><span>123</span></div> should be
considered as non-empty.
We should sync touch caret's visibility with caret every time since
touch caret might be hidden due to timeout while caret is enabled. Also
remove dead code.
Fixes:
./mach reftest error: runreftest.py: error: could not find the application path, --appname must be specified
--HG--
extra : rebase_source : 75c3c9ef00bceb0da418cdb592e736478dd442cb
