Identity block is misleading in reader mode

NEW
Unassigned

Status

()

P3
major
4 years ago
8 months ago

People

(Reporter: rctgamer3, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [reader-mode-firefox-integration])

(Reporter)

Description

4 years ago
If you feed Reader Mode a HTTPS URL, the identity block is completely absent from the url bar. This includes the company/organization and country label on sites with EV certificate(s).

Example URL: about:reader?url=https://blog.mozilla.org/addons/

Comment 1

4 years ago
I don't think that we should show the identity block, since about:reader is a local page in the browser, not a page served over the network.

However, this does raise an interesting point that we are indeed showing the globe icon and clicking on it gives an incorrect message.

We should probably update this to indicate that about:reader is a secure browser page, like we do on about:home. Although in case of loading about:reader directly, instead of from clicking the reader view button, we *do* perform a network request, which may not be encrypted. I'm not sure what UX pattern we should follow here.

Gijs, what do you think? Who's a good UX person to ask about site identity information?
Flags: needinfo?(gijskruitbosch+bugs)
Summary: Identity block not present on HTTPS pages in reader mode → Identity block is misleading in reader mode

Comment 2

4 years ago
(In reply to :Margaret Leibovic from comment #1)
> I don't think that we should show the identity block, since about:reader is
> a local page in the browser, not a page served over the network.
> 
> However, this does raise an interesting point that we are indeed showing the
> globe icon and clicking on it gives an incorrect message.
> 
> We should probably update this to indicate that about:reader is a secure
> browser page, like we do on about:home. Although in case of loading
> about:reader directly, instead of from clicking the reader view button, we
> *do* perform a network request, which may not be encrypted. I'm not sure
> what UX pattern we should follow here.

I think it should defer to the original URL. Imagine a nicely reader-mode formatted page that outlines you how to send all your personal bookmarks and history to a dodgy website that we label as being a browser page? That doesn't seem like a good idea.

> Gijs, what do you think? Who's a good UX person to ask about site identity
> information?

Per bug 1140774, shorlander!
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(shorlander)

Comment 3

4 years ago
(In reply to :Margaret Leibovic from comment #1)
> I don't think that we should show the identity block, since about:reader is
> a local page in the browser, not a page served over the network.

That's sort of like saying that this current page shouldn't show an identity block because browser.xul is a local page.

The "about:reader?url=" is hidden; the only thing shown is the page URL. It's just an alternate viewer for that page, so it should show the same identity block.

Comment 4

2 years ago
Johann, if we want to display the identity of the original webpage, does the identity block check originalURL? Or do we need to create some kind of special case?
Flags: needinfo?(jhofmann)
Priority: -- → P3

Updated

2 years ago
Flags: needinfo?(shorlander)
It does indeed not check that. In http://searchfox.org/mozilla-central/source/browser/base/content/browser.js#4560 we simply assign to gBrowser.currentURI.

A simple if clause like here http://searchfox.org/mozilla-central/source/browser/base/content/urlbarBindings.xml#618 should do the job, if I'm not mistaken.
Flags: needinfo?(jhofmann)
Ok, sorry, this will only display the correct URL in the identity popup. You want to change the whole identity block.

Then you will have to manipulate the state variable of gIdentityHandler as well. Since it's not really possible to know the security state without loading the page afaik (especially concerning content security). We have a few choices:

1) Simply display a green lock on https pages and no green lock on http pages (disregarding any possible network/certificate errors)
2) Go with Margaret's suggestion and create a special state for Reader Mode
3) Add some way in ReaderMode.jsm to save the original security state of the page.

Maybe 2) isn't such a bad idea after all.

Updated

2 years ago
Whiteboard: [reader-mode-firefox-integration]

Updated

8 months ago
Duplicate of this bug: 1441268
You need to log in before you can comment on or make changes to this bug.