(In reply to Timothy Nikkel (:tnikkel) from comment #4) > Presumably we get to here > > https://searchfox.org/mozilla-central/rev/7cadba1d8b8feaec4615f5bb98aac4b8a719793c/image/ProgressTracker.cpp#351 > > via the UpdateProxies call. Exactly. > So that means that mProgress on the progress tracker for the image has FLAG_LOAD_COMPLETE. How did it get there? It shouldn't be there yet. Okay, I know what's happened, Image do have FLAG_LOAD_COMPLETE at that time, imgRequest::OnStopRequest has called before, but it doesn't finish notifying observers in https://searchfox.org/mozilla-central/rev/9ad88f80aeedcd3cd7d7f63be07f577861727054/image/ProgressTracker.cpp#350 due to the spin event loop, stack is like https://pastebin.com/2X91amNp. So we see imgRequestProxy::OnLoadComplete from validating one get called first. So the case is like, 1. Loads an image that is not in the image cache, so we load it from the network. 2. Try to load same image again, hit image cache entry, so we start the validating process. 3. imgRequest::OnStopRequest get called, set mProgress on the progress tracker, but not finish notifying observers due to spin event loop. 4. imgCacheValidator::OnStartRequest is called and the request is still valid, so we notify the imgRequestProxy in https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/image/imgLoader.cpp#3005, which calls imgRequestProxy::OnLoadComplete. 5. Leave spin event loop (continue step 3), we end up calling imgRequestProxy::OnLoadComplete again, The call stack is as comment 0. But it seem the spin event loop just make the imgRequestProxy::OnLoadComplete calls in a different order. Even if no spin event loop involved, we would still call imgRequestProxy::OnLoadComplete twice (but in a sane order of course)?
Bug 1641682 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Timothy Nikkel (:tnikkel) from comment #4) > Presumably we get to here > > https://searchfox.org/mozilla-central/rev/7cadba1d8b8feaec4615f5bb98aac4b8a719793c/image/ProgressTracker.cpp#351 > > via the UpdateProxies call. Exactly. > So that means that mProgress on the progress tracker for the image has FLAG_LOAD_COMPLETE. How did it get there? It shouldn't be there yet. Okay, I know what's happened, Image do have FLAG_LOAD_COMPLETE at that time, imgRequest::OnStopRequest has called before, but it doesn't finish notifying observers in https://searchfox.org/mozilla-central/rev/9ad88f80aeedcd3cd7d7f63be07f577861727054/image/ProgressTracker.cpp#350 due to the spin event loop, stack is like https://pastebin.com/2X91amNp. So we see imgRequestProxy::OnLoadComplete from validating one get called first. So the case is like, 1. Loads an image that is not in the image cache, so we load it from the network. 2. Try to load same image again, hit image cache entry, so we start the validating process. 3. imgRequest::OnStopRequest get called, set mProgress on the progress tracker, but not finish notifying observers due to spin event loop. 4. imgCacheValidator::OnStartRequest is called and the request is still valid, so we notify the imgRequestProxy in https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/image/imgLoader.cpp#3005, which calls imgRequestProxy::OnLoadComplete. 5. Leave spin event loop (continue step 3), we end up calling imgRequestProxy::OnLoadComplete again, The call stack is as comment 0. But it seem the spin event loop just make the imgRequestProxy::OnLoadComplete calls in a different order. Even if there is no spin event loop involved, we would still call imgRequestProxy::OnLoadComplete twice (but in a sane order of course)?