Previously displayport bases were computed as the intersection of the
scrollport with the dirtyrect. However the dirtyrect covers what is
rendered, and with displayports what we render can be much larger than
what is visible. With displayport bases intended to represent what was
visible, this was a problem. By restricting them to the root composition
size this makes them more closely match what is visible. To do this more
properly we'd want to intersect the dirtyrect with the scroll clip of
every ancestor scroll frame, not just the root composition bounds.
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().
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.
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.
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.
What's happening here is that we enter an infinite loop by oscillating
between two states. The code assumes that (a) the available space will
never grow, only stay the same or shrink, and (b) that we should break
out of the loop if it stays the same. This also means we hit the
assertion about the available space growing every other time through the
loop.
This is in the inner loop in nsBlockFrame::ReflowBlockFrame that was
introduced in https://hg.mozilla.org/mozilla-central/rev/80ef9bb2c2e9 .
The problem is fundamentally a logic error in that code. The makes the
assumption that if you reduce the width available to a block formatting
context or replaced block-level element, its height does not shrink.
(The "replaced block" (really block formatting context) in this case, as
in the original testcase, is a scroll frame. I didn't debug the
original testcase enough to figure out what caused its sizing
characteristics, although a percentage-width image does seem like the
most likely candidate.)
Without the patch, the reftest test (but not reference) hangs, as does
the semi-simplified test in the bug (given a narrow window).
With the patch, neither the semi-simplified test in the bug nor the
reference hangs, and the reftest passes.
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.
