1235660 - HTTP instead of HTTPS shown in long press menu of a picture, when redirected from the HTTP to the HTTPS ressource using https-everywhere addon

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[oka33iex.ei4]

Attachment: Screenshot showing an example of the bug

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151223140742

Steps to reproduce:

On Firefox for Android with the https-everywhere addon installed:

1. Open a HTTP link to a picture ressource that has a redirect rule in https-everywhere. For example http://i.imgur.com/UBPupyH.jpg

2. The picture will load, with the HTTPS URL in the address bar, as expected.

3. Long press on the picture to open the context menu. It will still show the HTTP URL in the title of the context menu.

4. Select 'Copy Image Location' from the context menu. The copied URL will correctlly be the HTTPS one.


Actual results:

Opening a direct link to a picture via a HTTP URL that gets redirected to the HTTPS URL by https-everywhere will result in the long press menu of that picture still showing the HTTP URL.


Expected results:

The long press menu should show the correct URL, which is the HTTPS URL, as can be shown by copying the Image Location from said context menu.

Comment 1

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

This could be caused by the add-on or the browser, depending on how the add-on is written.

Andy, do you have any thoughts?

Comment 2

[Andy McKay]

Sounds like the add-on especially if it can't be reproduced without the add-on. I would contact the add-on author for more information. According to this page: https://www.eff.org/https-everywhere/development file a bug here: https://github.com/EFForg/https-everywhere/issues/

Comment 3

[oka33iex.ei4]

But shouldn't the long press menu show the correct URL of the displayed image regardless?

In my opinion this is a browser bug, because the add-on isn't changing the content of the long press menu (afaik, but it wouldn't make any sense). But it's so minor that it's probably not worth investigating. Just thought I'd report it anyway.

Comment 4

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to oka33iex.ei4 from comment #3)
> But shouldn't the long press menu show the correct URL of the displayed
> image regardless?

It depends on when the url is rewritten. For example, if https-everywhere rewrites all of the urls directly in the page, I think it should just work. However, they probably don't do this and rewrite the urls when they are loaded because the urls written into the page can be changed by JS (e.g. how Google search rewrites their urls to include tracking info).

If they're rewriting urls at load time, they probably have to rewrite them each time the url is "loaded": once for loading the page and once for copying it into the clipboard. Since desktop doesn't have this context menu issue, this case was probably overlooked on mobile.

In any case, since this isn't an issue with the browser without the add-on, I'd think we're not going to invest time into fixing this. I think the best chance to get movement on this bug would be to file it over at https-everywhere. If they find out it's a browser issue, we could take a look at it again.

Comment 5

[oka33iex.ei4]

Thanks you for the explanation!

I still don't really understand why the long press menu can't display the correct URL, since the 'Copy Image Location' in the very same menu is actually giving the correct URL.

But I agree with you that this is not worth investing time, unless it points to something more serious, which is apparently not the case.

I might still submit it to the https-everywhere issue tracker later.

Comment 6

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to oka33iex.ei4 from comment #5)
> I still don't really understand why the long press menu can't display the
> correct URL, since the 'Copy Image Location' in the very same menu is
> actually giving the correct URL.

The add-on may inject it's url-rewriting code in response to different browser actions (since it can't rewrite the page directly). The actions on desktop where it may do this is:
* Copy to clipboard (or image location, in this case)
* Load url

These likely come to the add-on for free on mobile.

However, since the dialog's title is mobile-specific, it could be an oversight on the part of the add-on developers to inject mobile-specific code in this case. It's also possible we don't have the appropriate API to allow them to inject code here.

Comment 7

[Francisco Jordano [:arcturus] [:francisco]]

Attachment: index.png

Hi folks,

I would close this bug as worksforme. Just tried out, restarted firefox for android after installing the add-on, and after checking the url provided, connection with the remote debugger shows the correct https in the img source and also the android dialog shows the correct information.

Comment 8

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Thanks for the update.