This prevents having the volume set to zero in some cases.
MozReview-Commit-ID: 4JSCDcd7jmT
--HG--
extra : rebase_source : bcc4b7229160e7cbe7ee4e7a4c712b497f7cbe16
The custom UA string sent by Sync now includes the "oscpu" portion of the
default UA string. Eg, with this patch my UA string looks like
"Firefox/49.0a1 (Windows NT 6.1; WOW64) FxSync/1.51.0.20160524173017.desktop"
where the value in parenthesis is added by this patch.
MozReview-Commit-ID: 1gfqQoVbO6V
--HG--
extra : rebase_source : 1098134f99bc7ac529c9124c8a565e5cdb24e7da
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
We hit an issue where adding a new env var, MOZ_DISABLE_TELEMETRY, added env10
and caused crashes. I suspect the issue is that there are is now a double-digit
number of env vars (bug 1277390). Here, we do the quick fix by removing
MOZ_DISABLE_TELEMETRY & repurposing MOZ_DISABLE_SWITCHBOARD to be generic.
While we're at it, we simplify the code by making the setDisabled methods a
strict getter without checking for how many times they're called.
MozReview-Commit-ID: 19DDbVYRZ2
--HG--
extra : rebase_source : 1590ae4f49bf725ab8a3bb26f10dab324903aa8c
In the previous implementation, we'd stop reading when the value would return
null, however, this breaks with SafeIntents where null is returned if a value
throws a runtime exception - i.e. we might stop reading at env2 if it throws
even though env3+ exist.
MozReview-Commit-ID: 7iZgUAjBSmB
--HG--
extra : rebase_source : a7440dd14bb406afcd6ac1ec514bf0b188b5b2b7
I feel this better follows the util class pattern: IntentUtils acts on Intents
as StringUtils would act on Strings.
MozReview-Commit-ID: 7n2B9q1KlSy
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/util/SafeIntent.java => mobile/android/base/java/org/mozilla/gecko/mozglue/SafeIntent.java
extra : rebase_source : ac953ac44f91f1d9b8fa4c0c2a21c539974e9df8
This gets used often enough that it's annoying to do full class name imports.
MozReview-Commit-ID: 7Yhp1NCgwQw
--HG--
extra : rebase_source : 4e4875153d171d8eb4c8ce49f8a6e6170ac5c616
- removed responsive.html/events.js
- added `isActiveForWindow` method to `ResponsiveUIManager`
- simplified how the check for RDM menu is done
- re-enabled tests for OS X debug in e10s
- refactored tests using `BrowserTestUtils`
MozReview-Commit-ID: 1TADh1dRVcU
