1466379 - Blocked images don't show image context menu

Status: VERIFIED FIXED

(Firefox :: Menus, defect, P3)

Description

[Kusanagi Kouichi]

Attachment: test.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180521230155

Steps to reproduce:

1. Set permissions.default.image to 2 or 3
2. Open the attached html
3. Right click on the image


Actual results:

It doesn't show image context menu.


Expected results:

It shows image context menu.

Comment 1

[Kusanagi Kouichi]

Firefox 58 is good. Firefox 59 and 60 are bad.

Comment 2

[Daniel_A[:daschilean] [Please contact - [e-mail]]]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 
Build ID: 20180503143129    
I manage to reproduce this issue on Ubuntu 16.04 x64 with the latest FF 60.0 (64bit). Please note that this issue is also displayed on FF 58.

Comment 3

[:Gijs (he/him)]

Jared and I bisected this down to bug 1406253.

Comment 4

[:Gijs (he/him)]

Attachment: Bug 1466379 - fall back to currentURI in case images are blocked,

Review commit: https://reviewboard.mozilla.org/r/249978/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/249978/

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8984177 [details]
Bug 1466379 - fall back to currentURI in case images are blocked,

https://reviewboard.mozilla.org/r/249978/#review256810

Comment 6

[Dão Gottwald [:dao]]

Comment on attachment 8984177 [details]
Bug 1466379 - fall back to currentURI in case images are blocked,

https://reviewboard.mozilla.org/r/249978/#review257904

Would it make sense for currentRequestFinalURI to fall back to currentURI automatically? The current behavior seems like a bit of a footgun?

Comment 7

[:Gijs (he/him)]

(In reply to Dão Gottwald [::dao] from comment #6)
> Comment on attachment 8984177 [details]
> Bug 1466379 - fall back to currentURI in case images are blocked,
> 
> https://reviewboard.mozilla.org/r/249978/#review257904
> 
> Would it make sense for currentRequestFinalURI to fall back to currentURI
> automatically? The current behavior seems like a bit of a footgun?

Good point. Indirectly this is exposing whether we have an mCurrentRequest, but if you wanted that information you could also/instead just use ctxt.getRequest(ctxt.CURRENT_REQUEST). I don't see any other particular reason not to do this. bz also reviewed the stuff in bug 1406253, Samael doesn't seem to be around, and bz is on holiday... maybe dholbert can help?

Comment 8

[Daniel Holbert [:dholbert]]

I don't really have any context / background knowledge around these image request APIs, so I'm not sure I can help here without doing a bunch of research and then just making a guess. :)  Probably best to wait for bz to weigh when he's back, next week?  Or if you need a quicker answer (e.g. to get this in before the merge), tnikkel or aosmond are probably more authoritative from an imagelib perspective.

Comment 9

[Daniel Holbert [:dholbert]]

(Alternately: if you're trying to get this in before the merge, then maybe it'd be simplest to just punt comment 7 to a followup simplification bug, to be circled back to after bz returns; and for now, just land the patch as it stands, since it has r+ from both of the currently-active stakeholders from the bug that added the API in question.)

Comment 10

[:Gijs (he/him)]

(In reply to Daniel Holbert [:dholbert] from comment #9)
> (Alternately: if you're trying to get this in before the merge, then maybe
> it'd be simplest to just punt comment 7 to a followup simplification bug, to
> be circled back to after bz returns; and for now, just land the patch as it
> stands, since it has r+ from both of the currently-active stakeholders from
> the bug that added the API in question.)

Let's do that. :-)

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7b5b59d44cea
fall back to currentURI in case images are blocked, r=bz,dao

Comment 12

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/7b5b59d44cea

Comment 13

[Mohammad Maruf Rahman]

I have reproduced this bug with Nightly 62.0a1 (2018-06-03)on Windows 10, 64 Bit!
This bug's fix is verified with latest Nightly!

Build ID 	20180624100132
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0

Comment 14

[Julien Cristau [:jcristau]]

Is this worth getting into esr60?

Comment 15

[Julien Cristau [:jcristau]]

Talked to Gijs on IRC, wontfix for esr60 because 1) this affects a non-default config, 2) this isn't tested.

Comment 16

[Anca Soncutean, Desktop QA]

I’ve reproduced this issue on Firefox 62.0a1 (20180603221731) under Windows 10 x64.
This behavior no longer occurs on Firefox 62.0b7 (20180709172241) under Windows 10 x64, Ubuntu 16.04 x64 and macOS 10.13.