Open Bug 1165592 Opened 9 years ago Updated 5 months ago

Identity block is misleading in reader mode

Categories

(Toolkit :: Reader Mode, defect, P3)

defect

Tracking

()

People

(Reporter: rctgamer3, Unassigned)

References

Details

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

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/
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
(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)
(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.
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
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.
Whiteboard: [reader-mode-firefox-integration]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(gijskruitbosch+bugs)
Severity: -- → S3
Flags: needinfo?(gijskruitbosch+bugs)
See Also: → 1651062
You need to log in before you can comment on or make changes to this bug.