| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
| |
With the big amount of code churn around DOM a lot of tests
broke severely enough that they caused build bustage.
This commit cleans up, removes or otherwise fixes tests
that are broken, no longer relevant or obsolete.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
along with it (1445670 and 1373780 part 2 and 3)
Convert dom/base/nsImageLoadingContent.cpp to use AsyncOpen2 and followups along with it (1445670 and 1373780 part 2 and 3)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In the original Windows clipboard BMP decoder implementation in
nsImageFromClipboard::ConvertColorBitMap, if the bitmap used bitfields
compression, it always adjusted the offset to the RGB data by 12 bytes.
It did this even for newer BMP header formats which explicitly include
space for the bitfields in their header sizes. This patch updates our
BMP decoder to do the same for clipboard BMPs, since we have observed
pasted BMPs using bitfield compression appearing incorrectly. To the
user this appears as if we read a color mask; completely red, blue,
green pixels at the start of the last row, causing all of the other rows
to start with the last three pixels of the previous row.
|
| |
|
|
|
| |
This gets rid of the old nsImageClipboard widget code in favor of using
the nsBMPDecoder in imglib.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are reading large image data (i.e.: people using webp to stream
video instead of the native webm format; I'm looking at you, Giphy!)
we can run into the situation where the available data is not in a
contiguous buffer, and we need to either buffer additional data or
re-buffer from the start. If we don't do this, we can run into issues
because of buffer over-reading (causing corrupted data if allocated or
more likely crashes if not allocated).
Re-buffering is expensive, but this should be rare and limited to
dealing with unintended use for animated image formats.
This resolves #940.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
See: https://github.com/MoonchildProductions/UXP/commit/622098073e132995994fac4d61e3629d08ee1801#commitcomment-31390051
|
| | |
|
| | |
|
| |
|
|
| |
(mRawSurface -> mVBuf)
|
| | |
|
| |
|
|
|
|
| |
Decoder/SurfacePipe methods.
Extend this change to nsWebPDecoder.cpp
|
| |
|
|
| |
updated imgFrame methods.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We currently choose to set the animation parameters (blend method, blend
rect, disposal method, timeout) in imgFrame::Finish instead of
imgFrame::InitForDecoder. The decoders themselves already have access to
the necessary information at the time InitForDecoder is called, so there
is no reason to do this. Moving the configuration to initialization will
allow us to relax the mutex protection on these parameters.
This part simply reorganizes imgFrame, and subsequent parts will
introduce the necessary changes to SurfacePipe and decoders.
|
| |
|
|
|
| |
This breaks animated WebP for the moment, but adds QCMS color management and lexer changes.
Tag #831
|
| |
|
|
|
| |
This creates a number of stubs and leaves some surrounding code that may be irrelevant (eg. recorded time stamps, status variables).
Stub resolution/removal should be a follow-up to this.
|
| |
|
|
| |
This should solve #483.
|
| | |
|
| |\
| |
| | |
Remove support and tests for HSTS priming from the tree. Fixes #384
|
| | | |
|
| |/ |
|
| |
|
|
| |
native in moebius
|
| | |
|
| |
|
|
| |
This resolves #91.
|
| |
|
|
| |
baseline (HTML forms)
|
| |
|
|
|
| |
This avoids manually hooking into shell32.dll and using the native shell API instead.
Tag #22.
|
| | |
|
| |
|
|
|
|
| |
A dimension of 3000 largest size x or y should cover all common caching cases for SVG icons and web app elements, but not caching large vector rasters that would exhaust the cache.
This limit is a royal 36MB/element (3000x3000x4) as cap (if the SVG is square). This avoids performance regressions when repeatedly scaling large vector images, but also allows for large SVG backgrounds to be cached.
It allows for the bad practice of slapping a large SVG on a site as html background, considering they are likely, even when using large sizes for "responsive" layout, not going to exceed 3000 px in the largest dimension (and if they do, the web designer needs to be slapped with a big trout).
|
| | |
|
| | |
|
| |
|
