User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180528100448 Steps to reproduce: Launch Firefox with WebRender enabled Install Brief 2.5.6 from AMO. Open https://en.wikipedia.org/w/api.php?action=featuredfeed&feed=featured&feedformat=atom If the pageAction icon is in the "Page actions" menu, right click it there and "Show in address bar". Actual results: The icon in the address bar is blank (not even any of the frames as the icon never fades to blank). Expected results: The page action icon is set to "/icons/brief.svg#pulsing", which is a CSS animated version, so the icon's animation should play (to indicate this is a feed preview page and Brief can be used to subscribe). This does work correctly in browser tabs or in the "Page actions" menu, but not in the address bar.

Doesn't seem like it's a blob-images bug (disabling invalidation or blobs does nothing)

Andrew, does this look like some sort of imagelib bug to you?

possibly the same root cause as https://bugzilla.mozilla.org/show_bug.cgi?id=1459760

I've tried bisecting this bug. Note that the steps to reproduce from the original report don't work for builds before https://hg.mozilla.org/integration/mozilla-inbound/rev/07ab807639ee as Brief did not use the problematic icon in that case. However, the icon from Brief still reproduces the problem. This is not a recent regression. Builds at least down to 2017-07-28 reproduce the same bug with WebRender enabled. Did not test earlier builds as they use different prefs to enable WebRender.

Attaching a minimal reproducer that can be used for old builds. Uses browser_action instead of page_action, but the same bug is observed with it.

Not sure this needs to block enabling WR on nightly. Certainly needs to be fixed before shipping though.

XUL doesn't properly fallback if there is no image container. We never give an image container for animated images. I need to look at the lingering concerns on why I disabled animated SVG image containers, and consider how best to reorganize the layout to fallback properly in general.

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a00d9d4e695b0a8385f410bd6e5604c802bc3c59

Comment on attachment 8986452 [details] [diff] [review] 0001-Bug-1464927-Make-nsImageBoxFrame-fallback-from-WebRe.patch, v1 Review of attachment 8986452 [details] [diff] [review]: ----------------------------------------------------------------- It seems like you are using the temp error draw result as a sentinel and not really to indicate a temporary error. Would it be better if you made nsImageBoxFrame::CreateWebRenderCommands return a bool as well as a draw result to indicate if it was succesful?

(In reply to Timothy Nikkel (:tnikkel) from comment #9) > Comment on attachment 8986452 [details] [diff] [review] > 0001-Bug-1464927-Make-nsImageBoxFrame-fallback-from-WebRe.patch, v1 > > Review of attachment 8986452 [details] [diff] [review]: > ----------------------------------------------------------------- > > It seems like you are using the temp error draw result as a sentinel and not > really to indicate a temporary error. Would it be better if you made > nsImageBoxFrame::CreateWebRenderCommands return a bool as well as a draw > result to indicate if it was succesful? Yes, you are right. I made it a Maybe.

Pushed by aosmond@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/39936912aca9 Make nsImageBoxFrame fallback from WebRender consistently with nsImageFrame. r=tnikkel

I'm not able to reproduce this issue, using the exact STR from Comment 0, Firefox Nightly (2018-05-28) under Ubuntu 16.04 (x64). Denis, can you still reproduce the issue? if yes, can you give me the updated steps?

Fixed for me since the patch for this bug landed.

I could reproduce this issue in original Nightly v62.0a1 (2018-05-28), but not fix build Nightly v62.0a1 (2018-06-22), Beta v62.0b3 or in Nightly v63.0a1 (2018-06-27). This issue is verified.