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.
This part is mainly to mark the channel as urgent-start if src related
attributes in HTMLImageElement and HTMLInputElement is set and the channel is
open due to user interaction. Unfortunately, we cannot just check the event
state just after creating channel since some loading image tasks will be queue
and execute in stable state. Thus, I store the event state in elements and
pass it to the place where create the channel.
MozReview-Commit-ID: GBdAkPfVzsn
--HG--
extra : rebase_source : 715352317b4b600f8a7f78b7bc22b894bb272d27
TimeStamp::ProcessCreations()'s aIsInconsistent outparam is ignored by the
majority of its caller. This patch makes it optional. Notably, this makes
ProcessCreation() easier to use in a constructor's initializer list.
This is a bug from https://hg.mozilla.org/mozilla-central/rev/2d171d75b746 (bug 1157546). It took a shortcut in trying to get around one of the downsides of tracking visibility on frames instead of content nodes.
We cannot get our primary frame during FrameCreate calls because FrameCreate is called during the frame's Init() function, which happens before the primary frame pointer is set.
So when TrackImage is called from FrameCreate |frame| will be null but mFrameCreateCalled will be true. So we won't hit the early return that tries to detect nonvisible images.
The comment being removed is just wrong. We can obtain a frame for <feImage> just as well as any other image type.
The thing that is different about <feImage> is that it calls IncApproximateVisibleCount() followed by FrameCreated() in the frame's Init() function. This means that the frame is marked visible at the time of the FrameCreated, and there will be no further calls to TrackImage (because there are no further changes). So the FrameCreated call is the last chance to mark this image visible. The regressing changeset tries to get around this by just considering the image visible whenever we know a frame exists (because of mFrameCreateCalled) but can't access it. This ends up affecting all types of images, not just <feImage>.
The above paragraph is also true for SVG <image> that are non-display.
nsImageLoadingContent::Notify is where all image notifications for things like <img> elements go through. The vast majority being implemented in C++. Any image observers implemented in JS must go through ScriptedNotificationObserver.
We only use ScriptedNotificationObserver in tests. The addon repository only has six hits, and four of them seem to be different versions of the same addon. And they don't seem to be among the more popular addons.
The original location of the assert only caught some images anyway. Things like CSS background images don't go through nsImageLoadingContent. ProgressTracker is the origin of all image notifications.
nsContentUtils::IsPatternMatching is the most common by far, but the
other is a generic location that may cover a number of issues.
MozReview-Commit-ID: Kli39btsqdd
--HG--
extra : rebase_source : 9ffdafb1f6654a90ab5e93594ffcb11e987f2b5e
nsContentUtils::IsPatternMatching is the most common by far, but the
other two are generic locations that may cover a number of issues.
MozReview-Commit-ID: Kli39btsqdd
--HG--
extra : rebase_source : 1a7eda2a711f079978b54012d9c7466bbd6de36f
This is refcounted as we'll need to hold strong references to the ImageTracker
from style structs that load images.
MozReview-Commit-ID: 994gE9tOjAn
--HG--
extra : rebase_source : 2d50059e51b42251c89a92a954cef7b49720ceba
Andrew Osmond
Yoshi Huang
Kris Maglione
Kershaw Chang
Jonathan Watt
Timothy Nikkel
Masatoshi Kimura
Sebastian Hengst
Wes Kocher
Nicholas Nethercote
Tom Tung
Boris Zbarsky
Sylvestre Ledru
Edgar Chen
Andrew McCreight
Cameron McCormack
Ben Tian
Iris Hsiao