searching for reviewer(tnikkel)
45e3f5d8e29402e8fda2fea772dc5d08d8866fd7: Bug 1446309 - Part 2. Make nsDisplayImage fallback to the previous image to avoid flickering. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 14 Aug 2018 11:35:40 -0400 - rev 829067
Push 118745 by maglione.k@gmail.com at Tue, 14 Aug 2018 20:34:55 +0000
Bug 1446309 - Part 2. Make nsDisplayImage fallback to the previous image to avoid flickering. r=tnikkel When the current image for an nsImageFrame/nsDisplayImage is not yet ready, we display the previous image, if any available, to avoid flickering while we wait for decoding to finish. On the WebRender path, this functionality was lost since we did not have the draw result information with image containers. With the API updated in part 1, we can now do this to avoid flickering.
69a4c2a0aac6e8bfc041a82b634611e1432af36b: Bug 1446309 - Part 1. Return draw result from imgIContainer::GetImageContainerAtSize. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 14 Aug 2018 11:35:40 -0400 - rev 829066
Push 118745 by maglione.k@gmail.com at Tue, 14 Aug 2018 20:34:55 +0000
Bug 1446309 - Part 1. Return draw result from imgIContainer::GetImageContainerAtSize. r=tnikkel In addition to the image container, the draw result can also be useful for callers to know whether or not the surface(s) in the container are fully decoded or not. This is used in subsequent parts to avoid flickering in some cases.
bc7ac43b0e134768d877b6bd46a127692846b63d: Bug 1416328 - Part 3. Enable img decoding attribute web-platform-tests. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Wed, 08 Aug 2018 07:56:01 -0400 - rev 827574
Push 118551 by bmo:mtigley@mozilla.com at Wed, 08 Aug 2018 15:37:58 +0000
Bug 1416328 - Part 3. Enable img decoding attribute web-platform-tests. r=tnikkel
630049a9ac3b24ec0a141669937df372373a5d6f: Bug 1416328 - Part 2. Expose decoding attribute for img elements. r=bz,tnikkel
Andrew Osmond <aosmond@mozilla.com> - Wed, 08 Aug 2018 07:56:01 -0400 - rev 827573
Push 118551 by bmo:mtigley@mozilla.com at Wed, 08 Aug 2018 15:37:58 +0000
Bug 1416328 - Part 2. Expose decoding attribute for img elements. r=bz,tnikkel This adds support for HTMLImageElement's decoding attribute, as described by: https://github.com/whatwg/html/pull/3221 https://whatpr.org/html/3221/images.html#decoding-images It also exposes the same attribute on SVGImageElement, just as Blink has chosen to do so.
1f426c672aabc1b58a4aceeaca499309afd9b66f: Bug 1416328 - Part 1. Add configurable synchronous decoding hint to nsImageLoadingContent. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Wed, 08 Aug 2018 07:56:01 -0400 - rev 827572
Push 118551 by bmo:mtigley@mozilla.com at Wed, 08 Aug 2018 15:37:58 +0000
Bug 1416328 - Part 1. Add configurable synchronous decoding hint to nsImageLoadingContent. r=tnikkel The next part in this series depends on this to implement the HTMLImageElement's decoding attribute. This functionality allows the caller to force an nsImageLoadingContent and its associated nsImageFrame and nsSVGImageFrame objects to synchronously decode an image at draw time. It will only synchronously decode if it has completed metadata decoding (i.e. knows its size) and has received all of the encoded data; this mirrors the load event criteria for an image.
1efeecd0ac69a8f5852ee48e3a5539e3b3e367e4: Bug 1474900: Assert there are no pending locks when destroying the image proxy. r=tnikkel
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 11 Jul 2018 17:06:40 +0200 - rev 827192
Push 118488 by bmo:hsivonen@hsivonen.fi at Tue, 07 Aug 2018 12:28:14 +0000
Bug 1474900: Assert there are no pending locks when destroying the image proxy. r=tnikkel
93fea376b688be74a3e68f196877afc46916081e: Bug 1479647 - Ensure that surface caches have consistent ordering between recording and replaying, r=tnikkel.
Brian Hackett <bhackett1024@gmail.com> - Tue, 31 Jul 2018 19:31:14 +0000 - rev 825952
Push 118215 by bmo:mtigley@mozilla.com at Thu, 02 Aug 2018 18:26:57 +0000
Bug 1479647 - Ensure that surface caches have consistent ordering between recording and replaying, r=tnikkel.
9851707b13cbcc41a970d677eab3a32d320e81dd: Bug 1471583: Don't record a successful draw result if the image is not complete yet. r=tnikkel
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 11 Jul 2018 15:13:35 +0200 - rev 817412
Push 116059 by dholbert@mozilla.com at Thu, 12 Jul 2018 16:48:41 +0000
Bug 1471583: Don't record a successful draw result if the image is not complete yet. r=tnikkel I've tried to unsuccessfully reproduce the same kind of failures locally under rr with this patch applied, so that's a good sign. This should fix the case where we don't invalidate from AttemptPartialUpdate while trying to sync-decode. This is a clear part of the problem, though not sure yet if it'll fix all the issues we see in these tests. In any case I want to investigate those separately. Differential Revision: https://phabricator.services.mozilla.com/D2068 MozReview-Commit-ID: H7OEvbQUues
853cf14dc4628cd431ed8ec3540a4afe6ca3f476: Bug 1470447 - JPEG decoder should post an invalidation for each row. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Wed, 11 Jul 2018 11:44:17 -0400 - rev 816950
Push 115900 by rwood@mozilla.com at Wed, 11 Jul 2018 17:33:59 +0000
Bug 1470447 - JPEG decoder should post an invalidation for each row. r=tnikkel The JPEG decoder will currently only post an invalidation when it has processed all of the rows it is able to. If it is has all the data, that means it must fully decode before invalidating. This causes very large JPEGs to appear in large chunks which feels janky compared to slowly appearing row by row with the refresh tick. With WebRender, it also allows us to upload less data per frame update which can be another source of jank.
e7732e4cb0c9abe6823f4f02313b0557ed33feab: Bug 1456111 - Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r=tnikkel
Matt Woodrow <mwoodrow@mozilla.com> - Tue, 10 Jul 2018 17:53:22 +1200 - rev 816103
Push 115761 by mhowell@mozilla.com at Tue, 10 Jul 2018 16:58:42 +0000
Bug 1456111 - Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r=tnikkel MozReview-Commit-ID: GGl7ul6aka1
87d46e61889ce56b2d391f41128a2fb1fbc4876c: Bug 1456111 - Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r?tnikkel draft
Matt Woodrow <mwoodrow@mozilla.com> - Tue, 10 Jul 2018 17:53:22 +1200 - rev 815869
Push 115670 by mwoodrow@mozilla.com at Tue, 10 Jul 2018 05:54:11 +0000
Bug 1456111 - Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r?tnikkel MozReview-Commit-ID: GGl7ul6aka1
33e19a7ad66420c29648b459214634eadb627cef: Bug 1473651: Track animated image status for generated content and content: url(). r=tnikkel
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 06 Jul 2018 10:22:09 +0000 - rev 815513
Push 115523 by bmo:tpodder@mozilla.com at Mon, 09 Jul 2018 00:41:46 +0000
Bug 1473651: Track animated image status for generated content and content: url(). r=tnikkel I thought of just moving the tracking to nsImageFrame instead of nsImageLoadingContent entirely, though that would mean I need to handle it also in nsImageBoxFrame and nsSVGImageFrame, which was even more duplicated code. Ideas for testing this welcome, though all our animated image test-cases are borked (all reftests in image/test/reftest/apng are disabled, and all the ones for gifs that have animations as well). I'll cross-ref this bug and bug 1473651 so that we can write a test for this once that's fixed. Differential Revision: https://phabricator.services.mozilla.com/D1994
ad56b08003a84f5bc1783cf38b760c41d9b915da: Bug 1472520 - Fix a crash when generating image decoder telemetry. r=tnikkel a=lizzard
Andrew Osmond <aosmond@mozilla.com> - Wed, 04 Jul 2018 08:50:02 -0400 - rev 815480
Push 115515 by bmo:edilee@mozilla.com at Sun, 08 Jul 2018 15:56:30 +0000
Bug 1472520 - Fix a crash when generating image decoder telemetry. r=tnikkel a=lizzard It is possible for a decoder's iterator to be invalid in some error conditions, all related to the ICO decoder seeking behaviour. Since we assume that the iterator is always valid for the purposes of generating the decoder's telemetry data, a malformed ICO image could cause a crash. This patch removes the assumption that the iterator is valid, and ensures we don't add the decoder's data to telemetry if it is invalid.
5019176ab037fe17b5eb38e6cbb08f562fc102c0: Bug 1472520 - Fix a crash when generating image decoder telemetry. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Wed, 04 Jul 2018 08:50:02 -0400 - rev 814105
Push 115101 by choller@mozilla.com at Wed, 04 Jul 2018 14:14:14 +0000
Bug 1472520 - Fix a crash when generating image decoder telemetry. r=tnikkel It is possible for a decoder's iterator to be invalid in some error conditions, all related to the ICO decoder seeking behaviour. Since we assume that the iterator is always valid for the purposes of generating the decoder's telemetry data, a malformed ICO image could cause a crash. This patch removes the assumption that the iterator is valid, and ensures we don't add the decoder's data to telemetry if it is invalid.
72416dd3422aca3e119b4ce0f80047f523aee5f7: Bug 215083: Remove sync image request clone. r=tnikkel
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 29 Jun 2018 23:56:49 +0200 - rev 812844
Push 114688 by bmo:oriol-bugzilla@hotmail.com at Sat, 30 Jun 2018 16:21:51 +0000
Bug 215083: Remove sync image request clone. r=tnikkel MozReview-Commit-ID: 59bXcnxfJTC
2ca43c308ce1c5063fd1f2be7984dc781ab70c0c: Bug 215083: Implement content: url(..) for elements. r=tnikkel,dholbert
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 16 May 2018 20:56:38 +0200 - rev 812843
Push 114688 by bmo:oriol-bugzilla@hotmail.com at Sat, 30 Jun 2018 16:21:51 +0000
Bug 215083: Implement content: url(..) for elements. r=tnikkel,dholbert Dynamic changes are handled correctly because content property changes already cause a reframe. This implements the same bits as Blink / WebKit do (single content item which is an image, otherwise gets ignored), except for the edge cases where you use this on an image. In order to handle the edge cases right, we completely isolate the nsImageLoadingContent usage based on `mKind`. Blink's and WebKit's behavior there makes no sense and it's erratic, what I implemented is consistent (we apply to images as long as they don't generate a box, and we don't look at alt text or broken icons), though I'll update to whatever the WG decides in https://github.com/w3c/csswg-drafts/issues/2831 / https://github.com/w3c/csswg-drafts/issues/2832. I don't think it matters in terms of web compat in any case. MozReview-Commit-ID: JUurhC60hWr
8d1f4fe78843a2948e244414ee8bdf46660bea39: Bug 1472145 - Part 2. Add telemetry to track how frequently WebP images are used. r=tnikkel data-r=chutten
Andrew Osmond <aosmond@mozilla.com> - Fri, 29 Jun 2018 20:30:08 -0400 - rev 812842
Push 114688 by bmo:oriol-bugzilla@hotmail.com at Sat, 30 Jun 2018 16:21:51 +0000
Bug 1472145 - Part 2. Add telemetry to track how frequently WebP images are used. r=tnikkel data-r=chutten This patch adds three telemetry scalars to track how WebP is used. All of these scalars are updated when we do the MIME type confirmation for an imgRequest when the first data comes in. We know at this point we decided to load the given content, so there should be minimal false positives for data the browser loaded but never displayed. The first two scalars are merely whether or not WebP was observed. One is for probes, which are tiny WebP images suggested by the Google WebP FAQ to probe for different aspects of WebP support (lossy, animated, etc). We want to count this separately as actual WebP content that the website wishes us to display. Probes will give a measure of how many users visit websites that probe for WebP support, and content will give a measure of how many websites don't care and just give us WebP images regardless. The third scalar is intended to give a relative measure of how many WebP images we are being served relative to all other image types. We expect the ratio to be small, but it would be good to confirm this from the data.
2a57944df012f4654b8f929132d7e3c5ab4193d0: Bug 1472145 - Part 1. Add support for identifying the WebP images MIME type. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Fri, 29 Jun 2018 20:30:05 -0400 - rev 812841
Push 114688 by bmo:oriol-bugzilla@hotmail.com at Sat, 30 Jun 2018 16:21:51 +0000
Bug 1472145 - Part 1. Add support for identifying the WebP images MIME type. r=tnikkel
698387dc78bacc77eeea7e0815c7df3a6754171c: Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 16 May 2018 20:56:38 +0200 - rev 812683
Push 114640 by bmo:emilio@crisal.io at Fri, 29 Jun 2018 20:18:50 +0000
Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert Dynamic changes are handled correctly because content property changes already cause a reframe. This implements the same bits as Blink / WebKit do (single content item which is an image, otherwise gets ignored), except for the edge cases where you use this on an image. In order to handle the edge cases right, we completely isolate the nsImageLoadingContent usage based on `mKind`. Blink's and WebKit's behavior there makes no sense and it's erratic, what I implemented is consistent (we apply to images as long as they don't generate a box, and we don't look at alt text or broken icons), though I'll update to whatever the WG decides in https://github.com/w3c/csswg-drafts/issues/2831 / https://github.com/w3c/csswg-drafts/issues/2832. I don't think it matters in terms of web compat in any case. MozReview-Commit-ID: JUurhC60hWr
1686eaf3c8bf079c96a7b9cdce24c78b6a6f08fd: Bug 1472053 - Tick the refresh driver instead of directly painting from nsViewManager::WillPaintWindow. r?tnikkel draft
Matt Woodrow <mwoodrow@mozilla.com> - Fri, 29 Jun 2018 13:40:22 +1200 - rev 812287
Push 114522 by mwoodrow@mozilla.com at Fri, 29 Jun 2018 01:40:48 +0000
Bug 1472053 - Tick the refresh driver instead of directly painting from nsViewManager::WillPaintWindow. r?tnikkel MozReview-Commit-ID: JQRSrRXfRQc
6fd25d53776fefdded81715dedbacc78453902c5: Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 16 May 2018 20:56:38 +0200 - rev 811312
Push 114261 by bmo:emilio@crisal.io at Wed, 27 Jun 2018 12:32:10 +0000
Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert Dynamic changes are handled correctly because content property changes already cause a reframe. This implements the same bits as Blink / WebKit do (single content item which is an image, otherwise gets ignored), except for the edge cases where you use this on an image. In order to handle the edge cases right, we completely isolate the nsImageLoadingContent usage based on `mKind`. Blink's and WebKit's behavior there makes no sense and it's erratic, what I implemented is consistent (we apply to images as long as they don't generate a box, and we don't look at alt text or broken icons), though I'll update to whatever the WG decides in https://github.com/w3c/csswg-drafts/issues/2831 / https://github.com/w3c/csswg-drafts/issues/2832. I don't think it matters in terms of web compat in any case. MozReview-Commit-ID: JUurhC60hWr
74e879273644ed14739026c596e1e172b115d4ef: Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 16 May 2018 20:56:38 +0200 - rev 811311
Push 114260 by bmo:emilio@crisal.io at Wed, 27 Jun 2018 12:26:03 +0000
Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert Dynamic changes are handled correctly because content property changes already cause a reframe. This implements the same bits as Blink / WebKit do (single content item which is an image, otherwise gets ignored), except for the edge cases where you use this on an image. Blink's and WebKit's behavior there makes no sense and it's erratic, what I implemented is consistent (we apply to images as long as they don't generate a box, and we don't look at alt text or broken icons), though I'll update to whatever the WG decides in https://github.com/w3c/csswg-drafts/issues/2831 / https://github.com/w3c/csswg-drafts/issues/2832. I don't think it matters in terms of web compat in any case. MozReview-Commit-ID: JUurhC60hWr
39936912aca97f641840e8d41da261932143de36: Bug 1464927 - Make nsImageBoxFrame fallback from WebRender consistently with nsImageFrame. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Fri, 22 Jun 2018 09:32:27 -0400 - rev 809605
Push 113724 by bmo:mstriemer@mozilla.com at Fri, 22 Jun 2018 14:48:42 +0000
Bug 1464927 - Make nsImageBoxFrame fallback from WebRender consistently with nsImageFrame. r=tnikkel Vector images don't support image containers if they are animated. In order to support this with WebRender, we would need to know when the generated shared surface was composited, so that we can update the image container on the next refresh tick. Because images use a different code path (not ImageClient), we don't have the ability at present. Changing vector images naively and just updating on every refresh tick if there is an image container to avoid fallback causes the animation to be very janky. Given nsImageFrame is already using fallback properly in this situation, then we can just fix nsImageBoxFrame to do the same. This gives acceptable performance without any visible slowness on the animation.
97d67e0eaccff918811b6f76fdf8c331bacf143e: Bug 1456111 - Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r=tnikkel
Matt Woodrow <mwoodrow@mozilla.com> - Thu, 21 Jun 2018 15:34:25 +1200 - rev 809346
Push 113651 by kgupta@mozilla.com at Thu, 21 Jun 2018 22:29:49 +0000
Bug 1456111 - Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r=tnikkel MozReview-Commit-ID: 1S59BARsMzZ
be2da60de34e1ab51c4231269cdf5ffd7f132c2c: Bug 1456111 - Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r?tnikkel draft
Matt Woodrow <mwoodrow@mozilla.com> - Thu, 21 Jun 2018 15:34:25 +1200 - rev 808869
Push 113534 by mwoodrow@mozilla.com at Thu, 21 Jun 2018 03:34:42 +0000
Bug 1456111 - Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r?tnikkel MozReview-Commit-ID: 1S59BARsMzZ
ad06fe901a300d45efa5e90e9a68005a595a3da8: Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 16 May 2018 20:56:38 +0200 - rev 808369
Push 113370 by bmo:emilio@crisal.io at Tue, 19 Jun 2018 11:33:09 +0000
Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert Take the review request as a feedback request for now. Pretty sure there's a bunch of image tracking stuff that could (should?) be done which is not done. Also need to figure out the right thing to do for animated images and that. That being said, this works. Dynamic changes are handled correctly because content property changes already cause a reframe. The mImage change for intrinsic sizing also fixes bug 1149357, since HTMLImageElement mungles the image natural width otherwise. I can (and will) submit that fix separately. This implements the same bits as Blink / WebKit do (single content item which is an image, otherwise gets ignored). MozReview-Commit-ID: JUurhC60hWr
b7098f9ed0a069a45841263869b7d40e6d522bc0: Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 16 May 2018 20:56:38 +0200 - rev 807911
Push 113242 by bmo:emilio@crisal.io at Sat, 16 Jun 2018 02:39:16 +0000
Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert Take the review request as a feedback request for now. Pretty sure there's a bunch of image tracking stuff that could (should?) be done which is not done. Also need to figure out the right thing to do for animated images and that. That being said, this works. Dynamic changes are handled correctly because content property changes already cause a reframe. The mImage change for intrinsic sizing also fixes bug 1149357, since HTMLImageElement mungles the image natural width otherwise. I can (and will) submit that fix separately. This implements the same bits as Blink / WebKit do (single content item which is an image, otherwise gets ignored). MozReview-Commit-ID: JUurhC60hWr
74487424ec36bf15f041e99dd57dd4c85052ebba: Bug 1453795 - Image - Initialize member fields in classes/ structures. r=tnikkel
Andi-Bogdan Postelnicu <bpostelnicu@mozilla.com> - Thu, 14 Jun 2018 08:21:37 +0300 - rev 807391
Push 113090 by bmo:m_kato@ga2.so-net.ne.jp at Thu, 14 Jun 2018 11:35:26 +0000
Bug 1453795 - Image - Initialize member fields in classes/ structures. r=tnikkel
6a84cdd1046f7508583b27a85e131b851afc115b: Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 16 May 2018 20:56:38 +0200 - rev 807066
Push 113036 by bmo:emilio@crisal.io at Wed, 13 Jun 2018 19:15:58 +0000
Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert Take the review request as a feedback request for now. Pretty sure there's a bunch of image tracking stuff that could (should?) be done which is not done. Also need to figure out the right thing to do for animated images and that. That being said, this works. Dynamic changes are handled correctly because content property changes already cause a reframe. The mImage change for intrinsic sizing also fixes bug 1149357, since HTMLImageElement mungles the image natural width otherwise. I can (and will) submit that fix separately. This implements the same bits as Blink / WebKit do (single content item which is an image, otherwise gets ignored). MozReview-Commit-ID: JUurhC60hWr
995feb0ecd7fc92e09329116ae4d6d5fcf94392b: Bug 1436409 - Remove the nsDisplayLayerEventRegions display item. r=mattwoodrow,tnikkel
Kartikaya Gupta <kgupta@mozilla.com> - Fri, 08 Jun 2018 17:31:27 -0400 - rev 806506
Push 112901 by bcampen@mozilla.com at Sun, 10 Jun 2018 18:18:51 +0000
Bug 1436409 - Remove the nsDisplayLayerEventRegions display item. r=mattwoodrow,tnikkel MozReview-Commit-ID: 6mw0WUGGT0n
53572697be3217d294daa3995b93d954e983da8f: Bug 1436409 - Remove the layout.event-regions.enabled pref and bake it in as false everywhere. r=tnikkel
Kartikaya Gupta <kgupta@mozilla.com> - Fri, 08 Jun 2018 17:31:27 -0400 - rev 806504
Push 112901 by bcampen@mozilla.com at Sun, 10 Jun 2018 18:18:51 +0000
Bug 1436409 - Remove the layout.event-regions.enabled pref and bake it in as false everywhere. r=tnikkel This pref was used to enable the building of nsDisplayLayerEventRegions items without APZ, so that we could test it in isolation. However, we no longer need to do so, and these display items are going to be deleted anyway, so we can remove this pref. MozReview-Commit-ID: LJVcFafCKyS
518882aa77b46e017b369032fc7ce5e68d9c87b9: Bug 1436409 - Remove the nsDisplayLayerEventRegions display item. r?tnikkel,mattwoodrow draft
Kartikaya Gupta <kgupta@mozilla.com> - Fri, 08 Jun 2018 17:31:27 -0400 - rev 806063
Push 112835 by kgupta@mozilla.com at Fri, 08 Jun 2018 21:32:33 +0000
Bug 1436409 - Remove the nsDisplayLayerEventRegions display item. r?tnikkel,mattwoodrow MozReview-Commit-ID: 6mw0WUGGT0n
d1a98a65e6d49ceecde1927fdae518ea4ea88d59: Bug 1436409 - Remove the layout.event-regions.enabled pref and bake it in as false everywhere. r?tnikkel draft
Kartikaya Gupta <kgupta@mozilla.com> - Fri, 08 Jun 2018 17:31:27 -0400 - rev 806061
Push 112835 by kgupta@mozilla.com at Fri, 08 Jun 2018 21:32:33 +0000
Bug 1436409 - Remove the layout.event-regions.enabled pref and bake it in as false everywhere. r?tnikkel This pref was used to enable the building of nsDisplayLayerEventRegions items without APZ, so that we could test it in isolation. However, we no longer need to do so, and these display items are going to be deleted anyway, so we can remove this pref. MozReview-Commit-ID: LJVcFafCKyS
8f10a838da3eb6eb8d7c6ff5b321565bfb8b527d: Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 16 May 2018 20:56:38 +0200 - rev 805666
Push 112736 by bmo:emilio@crisal.io at Fri, 08 Jun 2018 09:32:17 +0000
Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert Take the review request as a feedback request for now. Pretty sure there's a bunch of image tracking stuff that could (should?) be done which is not done. Also need to figure out the right thing to do for animated images and that. That being said, this works. Dynamic changes are handled correctly because content property changes already cause a reframe. The mImage change for intrinsic sizing also fixes bug 1149357, since HTMLImageElement mungles the image natural width otherwise. I can (and will) submit that fix separately. This implements the same bits as Blink / WebKit do (single content item which is an image, otherwise gets ignored). MozReview-Commit-ID: JUurhC60hWr
e2002e5279d13b2088f3d3c5e554ae4f64853d6c: Bug 920630 - Part 5. Remove image/ImageURL.h as unused. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 05 Jun 2018 20:42:57 -0400 - rev 804539
Push 112407 by bmo:ntim.bugs@gmail.com at Wed, 06 Jun 2018 09:28:54 +0000
Bug 920630 - Part 5. Remove image/ImageURL.h as unused. r=tnikkel
dcf212d04876742f581acab5f428e703b54de82f: Bug 920630 - Part 4. Change rest of imagelib to use nsIURI directly instead of ImageURL. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 05 Jun 2018 20:42:57 -0400 - rev 804538
Push 112407 by bmo:ntim.bugs@gmail.com at Wed, 06 Jun 2018 09:28:54 +0000
Bug 920630 - Part 4. Change rest of imagelib to use nsIURI directly instead of ImageURL. r=tnikkel
7597bbcc9d66111326aa69048ad5847bdc7497f2: Bug 920630 - Part 3. Change Image/ImageResource and derived classes to use nsIURI directly instead of ImageURL. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 05 Jun 2018 20:42:56 -0400 - rev 804537
Push 112407 by bmo:ntim.bugs@gmail.com at Wed, 06 Jun 2018 09:28:54 +0000
Bug 920630 - Part 3. Change Image/ImageResource and derived classes to use nsIURI directly instead of ImageURL. r=tnikkel
9f7a040f06f92605ca55f72b20a9863e906bfe2e: Bug 920630 - Part 2. Change ImageCacheKey to use nsIURI directly instead of ImageURL. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 05 Jun 2018 20:42:56 -0400 - rev 804536
Push 112407 by bmo:ntim.bugs@gmail.com at Wed, 06 Jun 2018 09:28:54 +0000
Bug 920630 - Part 2. Change ImageCacheKey to use nsIURI directly instead of ImageURL. r=tnikkel
ff2162607d61d0edd7db85c2e117b3d620c9d9ac: Bug 920630 - Part 1. Improve image logging to support direct logging of URIs and images objects. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 05 Jun 2018 20:42:56 -0400 - rev 804535
Push 112407 by bmo:ntim.bugs@gmail.com at Wed, 06 Jun 2018 09:28:54 +0000
Bug 920630 - Part 1. Improve image logging to support direct logging of URIs and images objects. r=tnikkel
47f3020c6aa74044419beb15c1518c155f021a03: Bug 1465775 - Fix crash in SourceBuffer::AppendFromInputStream due to incomplete read. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 05 Jun 2018 06:49:24 -0400 - rev 804176
Push 112321 by bmo:gl@mozilla.com at Tue, 05 Jun 2018 16:42:25 +0000
Bug 1465775 - Fix crash in SourceBuffer::AppendFromInputStream due to incomplete read. r=tnikkel Crash reports indicate that SourceBuffer::mStatus is not set, and thus SourceBuffer::AppendFromInputStream crashes due to dereferencing an invalid Maybe<nsresult> object. Since SourceBuffer::Append cannot fail without mStatus being set (or already set), it must mean that the input stream failed to read all the data, and swallowed any internal errors. While we used to assert in this situation, we also silently swallowed the error historically. This patch will check mStatus, but if it is unavailable, it will assert like before, and silently return otherwise.
4b9251f3824f18a20a0ac5a481577101993ae9d1: Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 16 May 2018 20:56:38 +0200 - rev 803241
Push 112049 by bmo:emilio@crisal.io at Sat, 02 Jun 2018 07:46:09 +0000
Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert Take the review request as a feedback request for now. Pretty sure there's a bunch of image tracking stuff that could (should?) be done which is not done. Also need to figure out the right thing to do for animated images and that. That being said, this works. Dynamic changes are handled correctly because content property changes already cause a reframe. The mImage change for intrinsic sizing also fixes bug 1149357, since HTMLImageElement mungles the image natural width otherwise. I can (and will) submit that fix separately. This implements the same bits as Blink / WebKit do (single content item which is an image, otherwise gets ignored). MozReview-Commit-ID: JUurhC60hWr
ba8bd19cb279e994d348bf5dcf67cfd73948876f: Bug 1445479 - Ensure we teardown requests on image cache validation failure paths. r=tnikkel, a=jcristau
Andrew Osmond <aosmond@mozilla.com> - Tue, 17 Apr 2018 14:42:35 -0400 - rev 802264
Push 111850 by bmo:tom@mozilla.com at Thu, 31 May 2018 16:41:37 +0000
Bug 1445479 - Ensure we teardown requests on image cache validation failure paths. r=tnikkel, a=jcristau If an imgCacheValidator object is destroyed without calling imgCacheValidator::OnStartRequest, or imgRequest::Init fails in OnStartRequest, we left the bound proxies hanging on an update. Now we cancel the new request, and bind the validating proxies to said request to ensure their listeners fail gracefully.
05b7e111b5c71c576292dbca958309c724c2e639: Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert draft
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 16 May 2018 20:56:38 +0200 - rev 801470
Push 111692 by bmo:emilio@crisal.io at Wed, 30 May 2018 14:57:21 +0000
Bug 215083: Implement content: url(..) for elements. r?tnikkel,dholbert Take the review request as a feedback request for now. Pretty sure there's a bunch of image tracking stuff that could (should?) be done which is not done. Also need to figure out the right thing to do for animated images and that. That being said, this works. Dynamic changes are handled correctly because content property changes already cause a reframe. The mImage change for intrinsic sizing also fixes bug 1149357, since HTMLImageElement mungles the image natural width otherwise. I can (and will) submit that fix separately. This implements the same bits as Blink / WebKit do (single content item which is an image, otherwise gets ignored). MozReview-Commit-ID: JUurhC60hWr
9b516954e1031202b00b924accfb0861a973986f: Bug 1462355 - Part 9. Lock animated imgFrame objects at creation rather than deferring. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 29 May 2018 08:36:13 -0400 - rev 801005
Push 111541 by bmo:emilio@crisal.io at Tue, 29 May 2018 15:58:21 +0000
Bug 1462355 - Part 9. Lock animated imgFrame objects at creation rather than deferring. r=tnikkel
8d412f560489b690870257077e15f1b1ad3d7b75: Bug 1462355 - Part 8. Avoid allocating on the heap in DrawableFrameRef. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 29 May 2018 08:36:13 -0400 - rev 801004
Push 111541 by bmo:emilio@crisal.io at Tue, 29 May 2018 15:58:21 +0000
Bug 1462355 - Part 8. Avoid allocating on the heap in DrawableFrameRef. r=tnikkel We can easily use Maybe<DataSourceSurface::ScopedMap> instead of allocated the map on the heap. This does require some minor changes to ScopedMap to properly support moves, but should be much more efficient.
baeab7da1768fb4741c1ee8942a04e70340fc3b4: Bug 1462355 - Part 7. Don't hit the SurfaceCache in FrameAnimator::GetCompositedFrame if possible. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 29 May 2018 08:36:13 -0400 - rev 801003
Push 111541 by bmo:emilio@crisal.io at Tue, 29 May 2018 15:58:21 +0000
Bug 1462355 - Part 7. Don't hit the SurfaceCache in FrameAnimator::GetCompositedFrame if possible. r=tnikkel In FrameAnimator::GetCompositedFrame, we call SurfaceCache::Lookup even when we use the composited frame directly and leave the lookup result unused. The only value in performing the lookup could be to mark the surface as used to avoid expiring it too soon, but FrameAnimator::RequestRefresh should already be doing enough to keep it alive, if the image isn't locked in the first place.
a7331d229cc8add978906ccc5582795bceb58d81: Bug 1462355 - Part 6. Reuse RawAccessFrameRef in FrameAnimator where possible. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 29 May 2018 08:36:12 -0400 - rev 801002
Push 111541 by bmo:emilio@crisal.io at Tue, 29 May 2018 15:58:21 +0000
Bug 1462355 - Part 6. Reuse RawAccessFrameRef in FrameAnimator where possible. r=tnikkel In FrameAnimator::RequestRefresh and AdvanceFrame, we currently create several RawAccessFrameRef objects to the same frames, either to get timeouts or perform the blending. With some tweaking, we can avoid requesting the same frame more than once. This will avoid mutex locks on the surface provider and the frame itself.
c67a6f1315b49a4faeec778709ab0d3a956a57dd: Bug 1462355 - Part 5. Avoid converting from DrawableFrameRef to RawAccessFrameRef. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 29 May 2018 08:36:12 -0400 - rev 801001
Push 111541 by bmo:emilio@crisal.io at Tue, 29 May 2018 15:58:21 +0000
Bug 1462355 - Part 5. Avoid converting from DrawableFrameRef to RawAccessFrameRef. r=tnikkel DrawableSurface only exposes DrawableFrameRef to its users. This is sufficient for the drawing related code in general, but FrameAnimator really needs RawAccessFrameRef to the underlying pixel data (which may be paletted). While one can get a RawAccessFrameRef from a DrawableFrameRef, it requires yet another lock of the imgFrame's mutex. We can avoid this extra lock if we just allow the callers to get the right data type in the first place.
93bdeed04a6b61139bc1c1b12088dafc260b3599: Bug 1462355 - Part 4. Remove imgFrame::GetAnimationData as it is no longer used. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 29 May 2018 08:36:12 -0400 - rev 801000
Push 111541 by bmo:emilio@crisal.io at Tue, 29 May 2018 15:58:21 +0000
Bug 1462355 - Part 4. Remove imgFrame::GetAnimationData as it is no longer used. r=tnikkel
45406c2b9e9cfa9fc2dd8cd80a35c82cf9480efc: Bug 1462355 - Part 3. Make FrameAnimator use the new imgFrame/RawAccessFrameRef methods. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 29 May 2018 08:36:12 -0400 - rev 800999
Push 111541 by bmo:emilio@crisal.io at Tue, 29 May 2018 15:58:21 +0000
Bug 1462355 - Part 3. Make FrameAnimator use the new imgFrame/RawAccessFrameRef methods. r=tnikkel