This limits us to 1 preloaded browser per window, in the top 3 normal windows + top 3 private windows.
If we try to create additional browsers beyond that, we instead move a pre-existing browser across.
Differential Revision: https://phabricator.services.mozilla.com/D21129
--HG--
extra : moz-landing-system : lando
The upcoming WebXR API (Bug 1419190) requires intermediate calculations of real-world space coordinates to have more precision with larger ranges. I expect that double precision matrix and quaternions will also be useful in other graphics and layout work.
It would not be ideal to expand the existing classes to always use double precision, as it would incur a significant performance penalty on certain platforms (eg, Arm). The double-precision variants should be used only when required.
The existing gfx::Matrix4x4 and gfx::Quaternion implementation can be extended with templates to generate both single and double precision variants.
Differential Revision: https://phabricator.services.mozilla.com/D22010
--HG--
extra : moz-landing-system : lando
- Modify ProcessDecodedData to return a MediaResult.
- RemoteDecoderParent::RecvInput and RemoteDecoderParent::RecvDrain
both use error returned from ProcessDecodedData to call SendError.
- RemoteVideoDecoderParent and RemoteAudioDecoderParent both return
MediaResult with NS_ERROR_OUT_OF_MEMORY if AllocShmem fails in
ProcessDecodedData (or if the returned buffer size is less than
the requested size).
Differential Revision: https://phabricator.services.mozilla.com/D23988
--HG--
extra : moz-landing-system : lando
This uses the Endian routines to ensure that reads will match the endianess
of the current machine, which is the expected behaviour of the openh264
plugin. The calls to readUint16 and readUint32 memcpy to a properly aligned
buffer avoiding any problems with alignment. The memcpy adds some overhead
but it seems negligible compared to the amount of work done to packetize and
send the encoded data.
These changes were tested by adding code to create an unaligned buffer and
memcopying the received buffer into it.
This also adds a null check for the received buffer as we have seen a small
volume of null pointer crashes.
Differential Revision: https://phabricator.services.mozilla.com/D24030
--HG--
extra : moz-landing-system : lando
The default color dictionary is implemented,to avoid hardcode color information. The functionality for overridding the values in formatter, is hitherto partially
implemented
Differential Revision: https://phabricator.services.mozilla.com/D23134
--HG--
extra : moz-landing-system : lando
The Flexbox Inspector uses platform APIs that don't take zoom into account whilst the Grid Inspector uses APIs that do take zoom into account.
This means that the zoom calculations when repositioning the canvas need to be different when called from the Flexbox Inspector than when called from the grid inspector.
I have added a `zoomWindow` option to `canvas.js::updateCanvasElement()` that allows us to optionally apply zoom to the current canvas position and the flexbox issue reported in the bug now works just fine.
All the usual other test cases work just fine with this patch applied.
Differential Revision: https://phabricator.services.mozilla.com/D23887
--HG--
extra : moz-landing-system : lando
This patch adds a timer for synchronous local storage requests. Once the timer
fires the request is canceled. The parent reports debugging information upon receiving cancellation.
Differential Revision: https://phabricator.services.mozilla.com/D24006
When changing addr_info we didn't always update addr_info_gencnt, so when it the old AddrInfo was freed, even though we lock in nsDNSRecord::GetNextAddr, mIter would still point to the old AddrInfo.
Differential Revision: https://phabricator.services.mozilla.com/D23923
--HG--
extra : moz-landing-system : lando
Currently for any screen with a ratio 1.6 or above, the preview uses a 16:10
image. However, the majority of Fx users have a screen that is 16:9[0], so for
most users the preview shows images distorted (compressed horizontally).
Originally I just added a new 16:9 version of the monitor image, but then I
realised I could save on filesize _and_ make it responsive to whatever the
user's screen actually is, rather than using arbitrary presets, by using
border-image.
The new image files are just sliced up versions of the original monitor.png
files, zopfli compressed to match (though with the power indicator dropped from
the Linux/Windows version to avoid distorting it). The combined filesize
savings seem to be 8.5KiB on macOS and 6.5KiB on Linux/Windows.
With the removal of the use of margins on the canvas we no longer need the
platform-specific setDesktopBackground.css file.
[0] https://data.firefox.com/dashboard/hardware
As of 3rd March 2019 the top three resolutions, 1366x768, 1080p, & 1600x900,
are all 16:9 and make up 67% of the userbase.
Differential Revision: https://phabricator.services.mozilla.com/D23114
--HG--
rename : browser/themes/linux/setDesktopBackground.css => browser/themes/shared/setDesktopBackground.css
extra : moz-landing-system : lando
nsHttpConnectionMgr::SpeculativeConnect may return early, without assigning ci to a RefPtr. In that case, we'd leak the nsHttpConnectionInfo. We need to have it in a RefPtr from the start to make sure we can't leak it.
Differential Revision: https://phabricator.services.mozilla.com/D23497
--HG--
extra : moz-landing-system : lando
And also don't blow the preferences away unless they actually change. We were
blowing them away whenever the document language changed or what not, that's not
good.
Differential Revision: https://phabricator.services.mozilla.com/D23955
--HG--
extra : moz-landing-system : lando
