| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
half-out-of-date MozInfra items from build/
|
| |
|
|
|
|
| |
such time it isn't a lost cause.
We are retaining the minor changes made elsewhere.
|
| |
|
|
|
|
|
|
| |
ui migration in prep for support of community-contributed language packs when Ascendant fully lands.
Language Pack policy will have to be established so once we take advantage of the fact that we have easy en-US generation without the former MozNonsense so we can support community-supplied locales or our own.
Though I am not entirely optimistic of the long term sustainability of language packs without either a team to produce them or users with true dedication to their contributed locale. But we shall see!
|
| | |
|
| |
|
|
| |
remain -moz-Dialog
|
| | |
|
| |
|
|
| |
This reverts commit 765406f5323117079d8d3de5b414f32c34757a9a.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
When installing an incompatible add-on, the add-ons manager checks first if a newer and compatible version of that add-on is available by sending a request either to the AUS or the provided update URL in the manifest.
If there's no update URL in the manifest and if the application does not provide an add-on update URL via preferences, the add-ons manager will error out and fail to notify that the said add-on is incompatible.
This commit addresses that by:
(a) preventing substitutions on the update manifest URL - this throws an error if it's empty; and
(b) failing early in the add-on update checker if the update manifest URL is empty and sends out an error notification
|
| | |
|
| | |
|
| |
|
|
|
| |
- Some encoders will set ctts flags incorrectly (similar to version) resulting in libstagefright aborting playback of media based on the media header.
- This change relaxes libstagefright's checking to pass ctts flags 0 or 1 and falls through to actually trying to decoding the file.
|
| |\ |
|
| | |
| |
| |
| | |
FFmpeg code
|
| | |
| |
| |
| | |
FFmpeg 5.0 removed some deprecated symbols so we need to update our decoding code to account for it.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
- UXP Parts 1, 2, 4, 5, and 7 based on Bug 1566141
- UXP Part 3 partially based on Bugs 1566141 and 1593415
- UXP Part 6 partly based on Bugs 1566141 and 1599163 with a different approach by modifying the `Boolish` function directly to act differently if we're checking for nullish values.
|
| |/ |
|
| |
|
|
|
|
|
|
| |
supportsHardwareH264Decoding() uses a promise if MP4 Hardware Acceleration to about:support
This concern was largely Mac-specific but I did leave Part 1 intact because the Mozilla Bug makes a good point that some systems may always software render a 64x64 video (specifically apple but other implementations could adopt this nonsense as well). Personally I want accelerated video.. damn it!
The real question is.. Why was the promise never resolving in the first place? Is it fall out from killing DOM Promise? It used jsval but who the hell knows or even cares.. It works and can once again be queried without jumping through god damned hoops.
|
| |
|
|
| |
flag due to Moonchild's continued incompetence which seems to be going further and further back.
|
| |
|
|
|
|
| |
necessary
As part of telemetry removal, Moonchild removed the `reportResult` function which also handles the stopping of the sanity test. This also removes unused histogram enumeration values and revises/adds some comments.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Even if `<datalist>` is dynamically changed, the autocomplete controller still
uses the previous search result. If changed, we have to ignore the previous
result that may now be invalid.
Also, even if `<datalist>` is changed, we have to keep the selected index
(See Mozilla Bug 595069), so we cannot use `ResetInternalState` in this
situation because it resets the selected index.
|
| |
|
|
| |
with the real version.
|
| | |
|
| | |
|
| |
|
|
| |
same domain as the page to avoid a busted feeds button/menu until something better comes along..."
|
| |
|
|
|
|
|
|
| |
In UXP Moonchild changed the implications for this security bug so it actually didn't do what Mozilla intended in an attempt to preserve functionality internally. He failed on both counts. This fix denies web access to any moz-icon but allows it to still work on other protocols like file: and about: etc.
We may want to re-visit the second part of our commit sha 6fa154c0adc64bd43775a79b7b508d87a486882b
Regardless, it seems to now perform as it was intended while not breaking stuff internally.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
PerformanceResourceTiming
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
the same as HTTP channels."
This reverts commit b17c689b521e44fcf6cbc0ffaa5b635466c95671.
|
| | |
|
| |
|
|
| |
instead of folder for most things
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
These were introduced in Bug 853388 for the sole purpose of tracking the current startup phase for telemetry
|
| | |
|
| |
|
|
|
|
|
|
| |
keyword table
This prevents the parser from accepting values outside the keyword table.
See GRE 3050 or UXP 1853
|
| |
|
|
| |
is a moron.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Add an extraction function to parse the RFC-6381 VP9 codec string.
* Add VP9-in-MP4 support to the decoder
* Use Codec detail extractor helper to tell if it's a new style VP8/VP9 codec string.
* Add a gtest for testing the extraction function.
* Add mBitDepth field to VideoInfo.
* Extract bit depth information from codec parameter string into VideoInfo::mBitDepth.
* Check bit depth in WebMDecoder to determine if we support HDR.
* Add an extraction function to parse the RFC-6381 VP9 codec string.
Based on Bug 1407919
|
| |
|
|
|
|
|
| |
as HTTP channels.
That is, treat it as a hint if called before open, and as an override if
called after. Override the hint on open.
|
