Closed Bug 1464927 Opened Last year Closed Last year
animated SVG page
Action in address bar not shown with Web Render
1.10 KB, application/x-xpinstall
7.05 KB, patch
|Details | Diff | Splinter Review|
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.
Component: Untriaged → Graphics: WebRender
Product: Firefox → Core
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Not sure this needs to block enabling WR on nightly. Certainly needs to be fixed before shipping though.
Assignee: nobody → aosmond
Status: NEW → ASSIGNED
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.
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.
Attachment #8986732 - Flags: review?(tnikkel) → review+
Pushed by firstname.lastname@example.org: 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.
You need to log in before you can comment on or make changes to this bug.