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.
Mostly automatic via sed. Only parts which I touched manually (apart from a
couple ones where I fixed indentation or which had mispelled arguments) are the
callers. I may have removed a couple redundant `virtual` keywords as well when
I started to do it manually, I can revert those if wanted.
Most of them are just removing the argument, but in Element.cpp I also added an
assertion for GetBindingParent when binding the ShadowRoot's kids (the binding
parent is set from the ShadowRoot constructor, and I don't think we bind a
shadow tree during unlink or what not which could cause a behavior difference).
Differential Revision: https://phabricator.services.mozilla.com/D2574
MozReview-Commit-ID: 2oIgatty2HU
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
The frame is notified via its mListener, which is an observer of the
nsImageLoadingContent (mContent).
This last one only notifies for the current and pending requests, otherwise it's
a bug we need to fix there, not wallpaper here, since that'd mean that we forgot
to cancel the previous request. Added assertions to that effect.
Notify() is only called with the this object as a first argument from
imgRequestProxy, so it'd better be non-null, too.
MozReview-Commit-ID: DHaOLph2EAo
ImageLoadingContent.currentURI returns the "URI" of currentRequest, which is
the URI used to start that request. Some consumers need to know the final URI
of that request instead.
If the image request gets redirected on loading (e.g. an add-on intercepts the
request), currentRequestFinalURI will be the redirected URI, while currentURI
would be the original URI before redirect.
MozReview-Commit-ID: 9lX063uAIp1
--HG--
extra : rebase_source : 91451128abc5c3f29c11d3cabfc98cde6c440ea6
ImageLoadingContent.currentURI returns the "URI" of currentRequest, which is
the URI used to start that request. Some consumers need to know the final URI
of that request instead.
If the image request gets redirected on loading (e.g. an add-on intercepts the
request), currentRequestFinalURI will be the redirected URI, while currentURI
would be the original URI before redirect.
MozReview-Commit-ID: 9lX063uAIp1
--HG--
extra : rebase_source : 6e9752b4df52e3874815557fe727c3fe94af2902
We queried 'loadingprincipal' attribute on the common call path, however
this should be queried if it's loaded by System Principal.
Also rename loadingprincipal to triggeringprincipal
The imgLoader code consistently uses the term 'loadingPrincipal' for the
principal that is called the triggeringPrincipal everywhere else it's used.
This is confusing, and since we need to make changes to how those values are
determined, it should be fixed beforehand.
MozReview-Commit-ID: 8CTHwayzcaD
--HG--
extra : rebase_source : d4405b0ecfe1c8dfb9bfdf61fe6ed6cfb180ba83
In order to let necko postpone the load of favicon, we have to set request context ID to the http channel that is created to load favicon.
This patch starts with passing a request context ID to nsContentUtils::LoadImage and makes other necessary changes to set the request context ID to the channel.
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
Use a boolean to prevent calling SetBlockedRequest asynchronously.
Also use the same boolean to prevent some evil code reenters LoadImage.
Then we should redesign the correct bahavior in those follow-up bugs,
Bug 1353685 - Should ServiceWorker call SetBlockedRequest
Bug 1353683 - consider calling SetBlockedRequest in nsCORSListenerProxy::UpdateChannel
Bug 1371237 - consider calling SetBlockedRequest in nsContentSecurityManager::CheckChannel
As a follow-up from bug 1206961, we will remove calling CanLoadImage in
this bug. Also in the case of CSP check failed, we will call
SetBlockedRequest in those cases.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1267075#c30 for the
analysis between the old and new setup.
Andrew Osmond
Emilio Cobos Álvarez
Robert Bartlensky
Margareta Eliza Balazs
shindli
Olli Pettay
Boris Zbarsky
Valentin Gosu
Chris Peterson
Brad Werth
Andreea Pavel
Samael Wang
Noemi Erli
Yoshi Huang
Kris Maglione
Kershaw Chang
Jonathan Watt
Timothy Nikkel
Masatoshi Kimura
Sebastian Hengst
Wes Kocher
Nicholas Nethercote