Previously, we removed records locally, but didn't notify the server.
We can be nice and avoid making the server buffer messages for
subscriptions that the client will never use again.
MozReview-Commit-ID: 5iohGQPHXuz
--HG--
extra : rebase_source : 00639fe1016ffd241c18643049f4b061740025f1
Even if the event handler calls `subscribe()` or `getSubscription()`,
the "readwrite" IDB transactions in `clearIf` and `forEachOrigin`
should execute first.
MozReview-Commit-ID: ETYGmnOIuag
--HG--
extra : rebase_source : 8f8847a825d1fcdb09a421b852e86b81431f7e8e
We forgot to check that the fraction part of second in the date was zero
if the time is midnight.
MozReview-Commit-ID: 7bMzFK8mBnO
--HG--
extra : transplant_source : %F3%29%5B%B7%F9O.IT%AB%2B%F4%F0iJ%CE%40%9CoN
MozReview-Commit-ID: 9e6HNAaF0Yo
In case of in-process restarts it can happen that the new process gets forked into a new process group.
When that happens we loose the capability to kill the process. To prevent a hang when joining the output
reader threads in wait(), we simply skip that call by passing-through the IO error.
--HG--
extra : rebase_source : 702dfec407ed13114f59fa6ccb0d82c5b0790550
CMD + a number key is a keyboard shortcut to select that tab number. (CMD+9 will always select the right-most tab, regardless of the tab count.) Currently, if the number is greater than the tab count, then the keyboard shortcut is ignored. With this patch, the right-most tab will be selected instead. For example, if there are five tabs and the user accidentally enters CMD+6 instead of CMD+5, selecting tab #5 is probably what they wanted instead of ignoring the keyboard shortcut.
Also expand the tab selection tests to cover more edge cases.
We should only attempt to demux new samples once all pending decoded frames have been returned. Otherwise, the next demuxing attempt once a resolution change has been detected will reset the state and drop all decoded frames.
MozReview-Commit-ID: 2coKQA8lZ8c
--HG--
extra : rebase_source : f8df34bd9ea1b05c251a34d043da19c7d3d5e587
For plain media playback, the buffered range will always be empty if readyState is HAVE_NOTHING has we need to decode the metadata to determine the duration and eventually decode the first frame to determine the start time. With MSE however, the buffered range is per spec directly related to the source buffer buffered range.
So we can always simply query the MediaDecoder to determine the buffered range regardless of the readyState value.
MozReview-Commit-ID: BQs8iuUCiNw
--HG--
extra : rebase_source : 28fea8a89eab38b481a15d76061debacce86274f
The index at which we are removing frames is always the one where we will be inserting the next ones.
MozReview-Commit-ID: DHeJDmwiMS9
--HG--
extra : rebase_source : 3730c0ed7fbdb4d9f8b4157f36aa7bb9d03a6517
We keep the next position on where to add frames so that we do not break the current coded frame group. However, when the new group of added frames starts with a keyframe we do not have to worry about breaking the previous coded frame group.
MozReview-Commit-ID: G81xGuSa4Y2
--HG--
extra : rebase_source : 4cbe5d0b5921c68c877815af15bbd10b40f18c80
WMF is very strict with the AudioSpecificConfig passed on and will error if an unknown extension is found. Attempt to detect those extensions and remove them if necessary.
MozReview-Commit-ID: KbooPiHmDbN
--HG--
extra : rebase_source : 849628daae33e0dca6ac3735dd8abc05e7554937
According to the Telemetry probes added in Bug 1271160, 1000ms should
account for ~94% of fullscreen transitions. The remaining ~6% tail is where
users might see the transition end and then content re-organize itself.
I think this is a big improvement over the original 500ms, which covers only
about ~80% of cases, according to Telemetry.
MozReview-Commit-ID: 3Vb9qQ7yDx5
--HG--
extra : rebase_source : 6f7a2db037bcd1ef21e59aca70b08078ab4f290d
