First, when the first node causing text is invisible, OnQueryTextRect() still fails even with this patch. We shouldn't fix it in this bug because it's unusual case but this bug is very important especially for some web service using HTML editor like Gmail.
This patch fixes all cases when the start offset of queried range reaches the end of mRootContent.
1. When the last node causing text is a <br> element (either content <br> element or moz-<br> element), its frame is a placeholder for empty line. Therefore, this patch sets the rect to the frame rect.
2. When the last node causing text is a text node, the last frame generated for it represents its line (including empty line). Therefore, this patch sets the rect to the result of GetLineBreakerRectAfter().
3. When the last node causes a line breaker before it, the frame may be a placeholder for it (this is not usual case, when user types Enter key at the end of <p> element, <p><br></p> is generated by Gecko). In this case, this patch sets a possible caret rect which is guessed from the content box of the frame and its font height.
4. When there are no nodes causing text in mRootContent, this patch sets a possible caret rect like case #3.
MozReview-Commit-ID: FS9cWJQ39DK
--HG--
extra : rebase_source : cb2ea4cfb4c8d5c85a4dd7498aa11bd86b61c2ef
Similar to OnQueryTextRect(), OnQueryTextRectArray() should compute a line breaker's rect with the last character when it's the first character in queried range and not caused by <br> frame.
MozReview-Commit-ID: CGDHbcrc6zB
--HG--
extra : rebase_source : 7e7cad1aebc4b1c675360a1a1ff6e704d17c4e5c
When queried range starts with a block frame, we cannot compute proper line breaker's rect at its open tag only with the frame's rect because the proper rect should be at the end of previous text frame.
Therefore, this patch makes SetRangeFromFlatTextOffset() return the last text node found at scanning the range. Then, OnQueryTextRect() can compute the first line breaker's rect with it (if there is at least one text node).
However, if the last text node is hidden by CSS or something, this patch won't work. We need to do something in another bug for hidden frame's issue, though. But note that IME typically doesn't request hidden text's rect because neither selection nor composition string is in such range.
MozReview-Commit-ID: 2FFzNoubJ1y
--HG--
extra : rebase_source : b9c4af40b8747f19da8e55434d580e29322c9601
In plain text editor, moz-<br> element is appended for a placeholder of empty line when the text ends with a line breaker. Therefore, when we compute text rects, we need to handle it same as a normal <br> element even though it doesn't cause any text.
MozReview-Commit-ID: 4IXLafU6o0W
--HG--
extra : rebase_source : 5db9c70e3acd40e4f47f35fcf293702ce0fb0295
Although, this patch is pretty big and complicated, but I have no idea to separate this since this rewrites all over the OnQueryTextRect() with new utility methods which are implemented for OnQueryTextRectArray().
Currently, OnQueryTextRect() doesn't support line breaks before block level elements. Therefore, in HTML editors, eQueryTextRect may not work fine if the range includes open tags of block level elements. This causes odd positioning of IME's candidate window in non-e10s mode.
This implements ContentEventHandler::GetLastFrameHavingFlatTextInRange() which scans the given range from last to first. However, this hits wrong NS_ASSERTION() in nsContentIterator::Last(). mLast can be nullptr if there is no content but Init() returns NS_OK even in such case. I think that returning NS_OK is fine because it's not illegal case. Therefore this patch fixes the wrong assertion.
MozReview-Commit-ID: E6OnIA1eMou
--HG--
extra : rebase_source : e44114b6fb0024c2ab7f9101b12335de4b5cc4aa
When the loop in ContentEventHandler::OnQueryTextRectArray() reaches at the end of contents, it should append a caret rect at the end of the contents. That helps deciding popup position of IME when caret is at the end of the contents.
This patch guesses the caret rect with eQueryTextRect event (for avoiding the dependency of native caret position of eQueryCaretRect event handler).
MozReview-Commit-ID: 8cGeHpkzX9g
--HG--
extra : rebase_source : c7adc65ccf0fefa7cb1c3bd0b056dc04f8a85b3e
This is hack for returning better rect for a line breaker caused by non-<br> element. E.g., if a block frame causes a line break, after the last visible character is the best position, i.e., there is |<p>ABC</p><p>DEF</p>| and the caret is after "C", querying next character's rect should be computed with "C"'s rect, rather than computed with next <p> element's border rect.
MozReview-Commit-ID: 7nXt74GGpNf
--HG--
extra : rebase_source : 14807e98cc9a6be22e6168570a299abf0ecaf267
If it returns frames which don't cause text, the caller needs complicated loop. So, it should return only frames which causes some text.
MozReview-Commit-ID: 9gny0w1PUMa
--HG--
extra : rebase_source : 423c7b57355d659e1a5bd96dac35060cae38801c
If line breakers in a text node works as is, e.g., |white-space: pre;| is specified, we need to handle line breakers in text frames too.
This patch handles "\n" in text nodes same as line breakers caused by some elements.
MozReview-Commit-ID: JmXesusFxzR
--HG--
extra : rebase_source : dca28a6e4661eef3c8a102916c451e0f021bf6d5
If the query range starts middle of a line breaker, i.e., "\r[\n", ContentEventHandler::OnQueryTextRectArray() does not need to (in other words, should not) append same rect anymore.
This patch checks if the range starts middle of a line breaker and in such case, skip to append same rect.
MozReview-Commit-ID: H5gdtAakGcP
--HG--
extra : rebase_source : 3afaca4d6e9f09e2054c4a6bd876635cfef6c58c
Some elements causes a line break before itself. In such case, OnQueryTextRectArray() should append one or two rects for such line breakers.
This patch also implements GetLineBreakerRectBefore(). It computes line breaker rect for the given frame. Even if it's a <br> frame, we cannot use its rect because <br> frame height is computed with line height but we need text's height (i.e., font height) and both height and width are 0 if it's in quirks mode and in non-empty line. Therefore, this patch computes it with frame's baseline, font's max-ascent and max-descent.
Although, this patch computes a line breaker rect caused by a open tag of a block level element with block frame's rect. However, it shouldn't be used actually as far as possible. Following patches will kill the path to the hack.
MozReview-Commit-ID: 9cym04j9NH9
--HG--
extra : rebase_source : 3117d68f056dc69550a16f52adade82049ba8277
When eQueryTextRect's query range length is 0 (this may be caused by native IME's bug), it should return caret rect. Therefore, it should redirect such query events to OnQueryCaretRect(). Such IME must want caret rect in such case.
MozReview-Commit-ID: JaUwhw1Cn5G
--HG--
extra : rebase_source : aef43e028fdf19b1e4977ce0d73e3fd700793ba9
ContentEventHandler::OnQueryTextRect() is now too complicated. So, we shouldn't duplicate similar code in OnQueryCaretRect(). When it needs to guess a caret rect from a character rect, we shouldn't compute character rect by itself.
MozReview-Commit-ID: 5G4MzQJzmoV
--HG--
extra : rebase_source : 31f2ec578eeb2af82b8af2d938448eb42afd50ea
This can kill the duplicated code in a lot of places in ContentEventHandler.
MozReview-Commit-ID: BRpBkbXyeBs
--HG--
extra : rebase_source : 98021e68cd0150149e6417c5a8f91979f5baad76
Currently, ContentEventHandler::SetRangeFromFlatTextOffset() sets end point to before a line breaker when the end of queried range is between a set of native line breakers (i.e., "\r]\n" on Windows). This causes unexpected empty range (e.g., "[]\n") when it queries a text rect at [\r]\n.
Therefore, it should select an XP line breaker in such case (i.e., the range should be "[\n]" when it queries "[\r]\n" or "\r[\n]").
Note that we don't need to do anything at setting selection start because it's always aligned to before the line breaker.
MozReview-Commit-ID: 6ht8QNAhibY
--HG--
extra : rebase_source : b7933554c2a5bf51b8faabe3a96d006971510e0a
This patch makes the static methods members of ContentEventHandler because ContentEventHandler::NodePosition is useful for them.
* nsINode* AdjustTextRectNode(nsINode*, int32_t&) -> NodePosition GetNodeHavingFlatText(nsINode* int32_t)
* nsIFrame* GetFirstFrameInRange(nsRange*, int32_t&) -> FrameAndNodeOffset GetFirstFrameHavingFlatTextInRange(nsRange*)
So, this patch avoids unclear in/out arguments of them.
MozReview-Commit-ID: 7yWeIkRdGj
--HG--
extra : rebase_source : 635cec95ee9f3d73f619186925464ae17010e929
Calling NotifyDataArrived from each sourcebuffer will cause multiple unnecessary NotifyDataArrived to the MediaFormatReader when it could only be done once. Additionally, it ensures that the media duration is updated prior to the reader actioning on the notification.
Extra: mEnded is only ever accessed on the main thread, there's no need to make it atomic.
MozReview-Commit-ID: IKq7IRBbWic
--HG--
extra : rebase_source : 6cf18b1f71f5ee6c8e82c73bdd2857e783f343b8
The duration in the MediaDecoder is the canonical. It has as such a more up to date value than the mirror.
Under some circumstances, the MDSM may have reached the end of media playback before the duration mirror had time to update. So perform the currentTime adjustment in the MediaDecoder instead.
MozReview-Commit-ID: 1RFr4mT5LpA
--HG--
extra : rebase_source : 3151d86561b53d5d1922c7c16f042792bfd47283
With MediaSource, the duration is always known and exact. It is entirely possible that we have played data at some point, then removed that data and adjusted the duration.
MozReview-Commit-ID: HZe2yXtQfIL
--HG--
extra : rebase_source : be1b57575c28142d6b3091b23894a7e4e1c9b405
Functions deprecated in GTK3 are often used for compatibility with GTK2
builds.
MozReview-Commit-ID: F220phw3wVO
--HG--
extra : rebase_source : 128e885652b184c5a7916378d9cebb067ab97eb0
1. Called from SourceBuffer::AppendDataCompletedWithSuccess() where mMediaSource->GetDecoder() is not null.
2. Called from MediaDecoder::ResourceCallback::NotifyBytesDownloaded() which is disconnected in Shutdown().
MozReview-Commit-ID: 103pxZP02Bb
--HG--
extra : rebase_source : 72e8a9c29d5ca6a4932de3a119497b05bfadbe68
1. Called from SourceBuffer::AppendDataCompletedWithSuccess() where mMediaSource->GetDecoder() is not null so this must happen before Shutdown().
2. Called from SourceBuffer::Ended() where mMediaSource->GetDecoder() is not null.
3. Called from MediaDecoder::ResourceCallback::TimerCallback() which is canceled in Disconnect().
MozReview-Commit-ID: 5dqVuOcrABy
--HG--
extra : rebase_source : a134f552c4fae2317cbf93dc1e861199d4c91346
This is a follow up from bug 1289623, as I missed a few cases in that bug.
MozReview-Commit-ID: DM7FtVSZUo3
--HG--
extra : rebase_source : 4fd7ae93b1418ded54f0c21a50a654fc962d4892
Bump deps. Previous deps resulting in failures with current builds.
MozReview-Commit-ID: BUEfDmmE00E
--HG--
extra : rebase_source : a5437a86a875531945c558fab9427c6c31059289
This file only uses functions on nsIXPConnect, so it can get it from
nsContentUtils and stop including xpcprivate.h, which eliminates
another file from being rebuilt when xpcprivate.h gets touched.
MozReview-Commit-ID: AT5Khu0vkyf
--HG--
extra : rebase_source : fa40afb7df9afe1dede714c111947e4e85aee34e
Add native method calls to AndroidGamepadManager to replace the gamepad
events in GeckoEvent. Implement those calls in AndroidGamepad.cpp. The
jni/Refs.h change is necessary to fix a compile error when using
jni::BooleanArray.
This also makes depth-textures follow filtering rules, whereas before we
allowed filtered depth textures for WEBGL_depth_texture.
MozReview-Commit-ID: LxepCb4WEkr
It is called from MediaSourceDecoder::SetMediaSourceDuration() which asserts !IsShutdown().
MozReview-Commit-ID: LF8rRPZhkA2
--HG--
extra : rebase_source : 886778f70d00e8670a203e9d322e442c9d117a72
1. It is called from SetInitialDuration() when mMediaSource is non-null which happens before Shutdown() which clears |mMediaSource|.
2. It is called from MediaSource::SetDuration() which happens before MediaSourceDecoder::Shutdown() for |mDecoder| is non-null.
3. It is called from MediaSource::DurationChange() where |mDecoder| is non-null.
MozReview-Commit-ID: 56AmWRLkkiv
--HG--
extra : rebase_source : 1f9443ac3670b12401ffa5ad397638c095e72566
1. It is called from OnSeekResolved() which asserts !IsShutdown().
2. It is called from UpdateLogicalPosition which asserts !IsShutdown().
MozReview-Commit-ID: J8iuHdUamLS
--HG--
extra : rebase_source : 97215383aa7c409f8b63f5a6726b81df53252227
1. Callbacks from the watch manager are disconnected in Shutdown().
2. It is called from MediaOmxCommonDecoder::NotifyOffloadPlayerPositionChanged() which will not happen after Shutdown().
3. It is called from MediaOmxCommonDecoder::ResumeStateMachine() which returns early when IsShutdown() is true.
MozReview-Commit-ID: COmPFaQzNTq
--HG--
extra : rebase_source : ac88698c66f4586b00fe62ad4dcdbb1cb4ce8542
The spec requires the MediaKeyStatusMap.get(keyId) function to return an 'any'
type, which is undefined for known keys, or a MediaKeyStatus enum value for
known keys.
https://w3c.github.io/encrypted-media/#idl-def-mediakeystatusmap
MozReview-Commit-ID: 3TOFYLacZSc
--HG--
extra : rebase_source : cd067f545cdbd9352ba64fea914128201b458d9c
1. It is called from DormantTimerExpired(). The timer is canceled in Shutdown().
2. It is called from NotifyOwnerActivityChanged() which happens before Shutdown().
3. It is called from Play() which happens before Shutdown().
4. It is called from Seek() which happens before Shutdown().
MozReview-Commit-ID: EnKHF61FBXf
--HG--
extra : rebase_source : 04df59b6722c8340e5163a00eb916442799cfcf1
We don't need to check IsShutdown() which is a subset of |mPlayState != PLAY_STATE_PAUSED && !IsEnded()|.
MozReview-Commit-ID: BjYoLOLuPfC
--HG--
extra : rebase_source : 0d04b30a8bf955faed4907f77f0da29e0ccc011d
1. It is called from DurationChanged() which returns early when IsShutdown() is true.
2. It is called from Play() when IsEnded() is true.
MozReview-Commit-ID: Ixy5OMZHxIm
--HG--
extra : rebase_source : 4cd7229084c6af8b7123ee6c85156ef4932308f3
1. It is called from ChangeState() when IsEnded() is true.
2. It is called from OnMetadataUpdate(). The callback is disconnected in Shutdown().
MozReview-Commit-ID: 8m4jtcl91hT
--HG--
extra : rebase_source : 0988128ec6d05f07ab7b072cc70a9c2970c829c5
1. Pause() is called from HTMLMediaElement and happens before Shutdown().
2. Pause() is called from SetPlaybackRate() which is called from HTMLMediaElement.
MozReview-Commit-ID: DDr7Bg8jkF2
--HG--
extra : rebase_source : 8b8a4fdc914d0bce7572d9a1ccb0f530bdba062c
FireTimeUpdate() is only called from UpdateLogicalPositionInternal() which returns early when IsShutdown() is true.
MozReview-Commit-ID: 4GZwrI85aXj
--HG--
extra : rebase_source : 9d7cbd571fd794369c833723ea5fc50a26380e51
1. ConstructMediaTracks() is called from ChangeState() when |mPlayState == PLAY_STATE_PLAYING|.
2. ConstructMediaTracks() is called from MetadataLoaded() which asserts |!IsShutdown()|.
MozReview-Commit-ID: 6OaPYcCOCii
--HG--
extra : rebase_source : 9db9e841fe8a0d797a39cd527abf4f4e95b67131
We want the maximum scroll position to be aligned with layer pixels. That way
we don't have to re-rasterize the scrolled contents once scrolling hits the
edge of the scrollable area.
Here's how we determine the maximum scroll position: We get the scroll port
rect, snapped to layer pixels. Then we get the scrolled rect and also snap
that to layer pixels. The maximum scroll position is set to the difference
between right/bottom edges of these rectangles.
Now the scrollable area is computed by adding this maximum scroll position
to the unsnapped scroll port size.
The underlying idea here is: Pretend we have overflow:visible so that the
scrolled contents start at (0, 0) relative to the scroll port and spill over
the scroll port edges. When these contents are rendered, their rendering is
snapped to layer pixels. We want those exact pixels to be accessible by
scrolling.
This way of computing the snapped scrollable area ensures that, if you scroll
to the maximum scroll position, the right/bottom edges of the rendered
scrolled contents line up exactly with the right/bottom edges of the scroll
port. The scrolled contents are neither cut off nor are they moved too far.
(This is something that no other browser engine gets completely right, see the
testcase in bug 1012752.)
There are also a few disadvantages to this solution. We snap to layer pixels,
and the size of a layer pixel can depend on the zoom level, the document
resolution, the current screen's scale factor, and CSS transforms. The snap
origin is the position of the reference frame. So a change to any of these
things can influence the scrollable area and the maximum scroll position.
This patch does not make us adjust the current scroll position in the event
that the maximum scroll position changes such that the current scroll position
would be out of range, unless there's a reflow of the scrolled contents. This
means that we can sometimes render a slightly inconsistent state where the
current scroll position exceeds the maximum scroll position. We can fix this
once it turns out to be a problem; I doubt that it will be a problem because
none of the other browsers seems to prevent this problem either.
The size of the scrollable area is exposed through the DOM properties
scrollWidth and scrollHeight. At the moment, these are integer properties, so
their value is rounded to the nearest CSS pixel. Before this patch, the
returned value would always be within 0.5 CSS pixels of the value that layout
computed for the content's scrollable overflow based on the CSS styles of the
contents.
Now that scrollWidth and scrollHeight also depend on pixel snapping, their
values can deviate by up to one layer pixel from what the page might expect
based on the styles of the contents. This change requires a few changes to
existing tests.
The fact that scrollWidth and scrollHeight can change based on the position of
the scrollable element and the zoom level / resolution may surprise some web
pages. However, this also seems to happen in Edge. Edge seems to always round
scrollWidth and scrollHeight upwards, possibly to their equivalent of layout
device pixels.
MozReview-Commit-ID: 3LFV7Lio4tG
--HG--
extra : rebase_source : 3e4e0b60493397e61283aa1d7fd93d7c197dec29
extra : source : d43c2d5e87f31ff47d7f3ada66c3f5f27cef84a9
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
Remove string comparisons to determine from mime types if content is VPX or
H264. Replace with calls to VPXDecoder::IsVPX or MP4Decoder::IsH264 to
centralise such logic.
This patch introduces MP4Decoder:IsH264, and moves the similar functionality out
of H264Convertor for the sake of consistently having these functions in
decoders.
MozReview-Commit-ID: 5nfYusYHrUR
--HG--
extra : rebase_source : c013c4ebe28d5afedbb91ddfffadb40d23fd0ee3
After a video has been playing while hidden for a certain time, count the time
until it is not hidden anymore (or it has finished playing), to test-drive how
much decoding time would have been saved by the video-decode-suspend feature.
Note that this is done inside HTMLMediaElement by simulating what should happen
in the MDSM, because instrumenting the MDSM itself and friends would have been
harder and more intrusive.
MozReview-Commit-ID: LdxhPtmoXeA
--HG--
extra : rebase_source : c4063d7c39b56e62e4f397bc21ef889ed14307c8
Previously the tests would check if playback had started by looking at the first
recorded time, and then looking at the current time. If there were a lag it was
possible for the first recorded time to be at the end of the video (i.e.
playback already finished), in which case the video playing would not register.
This patch instead uses the played ranges from the video element. Now so long as
there is a non-empty played range we trust playback started.
MozReview-Commit-ID: 5C39A42KRdj
--HG--
extra : rebase_source : e4e8a35df3bac4c9e7765272acb6300b44b45d4e
GetFirstFrameInRange() uses AdjustTextRectNode() which may return different node before retrieving the result frame. Therefore, the caller may need offset in the new node.
MozReview-Commit-ID: 2AQU5WfahT9
--HG--
extra : rebase_source : c753d34dc2691da2ec25c9f5a6fe17d67af24a70
We need to update mLastComputedValue while processing events that occur at the
same time rather than just skipping over them.
MozReview-Commit-ID: LuxSK6PHFHv
--HG--
extra : rebase_source : be323da2a50ea32838aef322267115d153a14c3d
After a video has been playing while hidden for a certain time, count the time
until it is not hidden anymore (or it has finished playing), to test-drive how
much decoding time would have been saved by the video-decode-suspend feature.
Note that this is done inside HTMLMediaElement by simulating what should happen
in the MDSM, because instrumenting the MDSM itself and friends would have been
harder and more intrusive.
MozReview-Commit-ID: LdxhPtmoXeA
--HG--
extra : rebase_source : 151e1f1383ab5c445eb8c957be8363340cdc4ab1
This behaviour changed as part of Bug 1279493, and the tests should be updated
to reflect this.
MozReview-Commit-ID: oITf0hVjKk
--HG--
extra : rebase_source : 26f54e0ac49a2f27f364c75a63851df5a85ce18f
