Bug 1180991 - [e10s] Page Info: Media preview is not shown the first time on multi-process Nightly

Good STR, I can reproduce. So what’s going wrong here?

Huh… and when I set a breakpoint in pageinfo.js’s makePreview, the bug goes away. Smells like a race!

Ahhh… the image is being set properly, but in the cases where the image doesn’t show, it looks like the width and the height aren’t being set properly. Interesting...

Also, this seems to only apply to images of type Background. Interesting...

Ah, heh, yep - jimicy already noticed this . Should have read the bug all the way through.

Okay, I think I’ve solved this one.

The thing is that in single-process, the image sources have been loaded in the same process, so the cache is able to set things like the naturalHeight and naturalWidth on the preview image immediately.

In multi-process, images are loaded in a separate process, which means that we have to hit some async part of the cache. naturalWidth and naturalHeight are 0 on the preview image, and we just roll with that.

So part of the solution is to get the naturalWidth and naturalHeight from the child.

One wrinkle though, is the favicon. Favicons aren’t actually loaded by the content process - they’re loaded by the parent process. So in that case, we want to go with the old technique.

#aux-nav .other-apps a {

padding-left:24px;

background-repeat:no-repeat;

background-position:left 4px;

background-image:url(../../img/app-icons/16/sprite.png?33db7a2)

}

Okay… there’s still a problem here. The problem is that background images that are not displayed (example, in a display:none block) are not shown. Interesting.

The problem is that for those images, they’re not yet loaded - they load after the fact. Okay, I guess one could make the media node pumping more async.

Conclusion: I think we should RESOLVE this bug and file a new bug for this special-case. I think the new bug should not block e10s, even if it’s a regression.

To be honest, I think a lot of the PageInfo mechanism can be rewritten.