UpdateOverflow and RecomputeOverflow need to remain two separate
functions since RecomputeOverflow is called from line layout, prior to
setting the overflow areas, whereas UpdateOverflow needs to reset the
overflow areas and (via its return value) propagate the change to
ancestors. However, they should share more code than they do today.
The only substantive (non-error-handling) change this is making is that
it's adding the MeasureText call, manipulation of the resulting
boundingBox, and inclusion of that bounding box in the visual overflow.
This is exactly the change that I'm trying to make in this bug.
It's also changing the error handling if EnsureTextRun returns null, but
I don't think we need to worry about that case much.
IOW, drop the requirement that the parent *content* is a <fieldset>,
thus allowing a <legend> to become the fieldset legend also when it's
wrapped in one or more nodes that are styled with display:contents.
IOW, drop the requirement that the parent *content* is a <fieldset>,
thus allowing a <legend> to become the fieldset legend also when it's
wrapped in one or more nodes that are styled with display:contents.
For me, this reduces the load time of the testcase in bug 1139709 from
68s to 34s.
--HG--
extra : rebase_source : 3b308584a9985e5ce55297fff6bb7f35acadcf0e
This test is fundamentally racey - it loads very short video files (some less
than 1s), plays them, waits for timeupdate events to try to find just the right
moment to seek, performs a seek, and then checks various pieces of
playback-dependent state (while playing).
The specific issue I ran into was that the video would sometimes finish playing
before the 'seeked' event handler fired, which means that readyState is
HAVE_CURRENT_DATA (per spec). I could fiddle with the test a bit to handle this
case, but I think we're doing a disservice to ourselves by having it in the tree.
The use of play() and pause() in the test is hugely problematic for short video
files and slow/laggy platforms. In particular, if playback has ended by
the time that we fire the 'seeked' event listener, then the ensuing play() will
put us back into seeking mode (seeking to 0), making the test fail.
This means that we can get rid of the code to recheck state after dropping the
monitor. We'll remove the other monitor drop from this method in a subsequent
patch.
This has two implications:
* We no longer need to pipe mQueuedSeekTarget through MDSM::Seek to get the
appropriate clamping.
* MDSM::Seek doesn't _need_ to be called on the main thread anymore.
The ogg reader makes two adjustments to the seek time - the first is to clamp it
between start and end time, which MDSM already does. The second is to subtract
SEEK_OPUS_PREROLL from the target. If we wanted to, we could return this as the
resolve value in the seek promise and handle the update in the MDSM. But I think
DropVideoUpToSeekTarget should actually handle this just fine.
The model we're moving towards is one where the MDSM can just disconnect all of
its promises, send a ResetDecode down the pipe, and start doing something
unrelated.
I traced this back to something 2011 or earlier and then gave up. Given that we're
doing an exact microsecond comparison here this is almost certainly dead code in
every case except for the one where the media is paused and JS does
|el.currentTime = el.currentTime|. And in that case, I think running through the
regular seek machinery is probably fine.
