Closed Bug 1466379 Opened Last year Closed Last year

Blocked images don't show image context menu

Categories

(Firefox :: Menus, defect, P3)

59 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 62
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- verified

People

(Reporter: slash, Assigned: Gijs)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files)

Attached file 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.
Firefox 58 is good. Firefox 59 and 60 are bad.
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.
Status: UNCONFIRMED → NEW
Component: Untriaged → Menus
Ever confirmed: true
Jared and I bisected this down to bug 1406253.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Comment on attachment 8984177 [details]
Bug 1466379 - fall back to currentURI in case images are blocked,

https://reviewboard.mozilla.org/r/249978/#review256810
Attachment #8984177 - Flags: review?(bzbarsky) → review+
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?
Attachment #8984177 - Flags: review?(dao+bmo) → review+
(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?
Flags: needinfo?(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.
Flags: needinfo?(dholbert)
Flags: needinfo?(gijskruitbosch+bugs)
(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.)
(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. :-)
Flags: needinfo?(gijskruitbosch+bugs)
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/7b5b59d44cea
fall back to currentURI in case images are blocked, r=bz,dao
Depends on: 1469996
https://hg.mozilla.org/mozilla-central/rev/7b5b59d44cea
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 62
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
QA Whiteboard: [bugday-20180620]
Is this worth getting into esr60?
Version: 60 Branch → 59 Branch
Talked to Gijs on IRC, wontfix for esr60 because 1) this affects a non-default config, 2) this isn't tested.
Flags: qe-verify+
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.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.