1642235 - Clicking on any Add-on on the about:addons menu causes an error.

Status: RESOLVED DUPLICATE of bug 1645286

(Core :: DOM: Navigation, defect)

Description

[Gary [:streetwolf52]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

1. Go to about:addons

2. Click on any Add-on in the list

Actual results:

The following error message is produced:

The address wasn’t understood

Firefox doesn’t know how to open this address, because one of the following protocols (addons) isn’t associated with any program or is not allowed in this context.

You might need to install other software to open this address.

Expected results:

The normal menu for the add-on should have appeared.

Clicking on the Try Again button usually produces the correct menu as well as choosing the Manage option from the drop down menu for the add-on.

Also all add-ons might disappear. A page refresh will get them back.

The link when clicking on the add-on appears like:

addons://detail/{446900e4-71c2-419f-a6a7-df9c091e268b}

Comment 1

[Alice0775 White]

I can reproduce the issue when I click on addon name label.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=14a902630badfa3c7ddbfe3c95fc959eddd6685d&tochange=3e61fd04eac7893a5a98a874ec9bb20fe218d310

Comment 2

[Alice0775 White]

[Tracking Requested - why for this release]: Add-on Manager broken

Comment 3

[Alex]

Can confirm on 78b2

Comment 4

[Jean-Yves Avenard [:jya]]

will take a look

Comment 5

[Gary [:streetwolf52]]

Just discovered something interesting. The address error only happen when I hover my pointer over the name of the add-on where it shows addons://detail/........ on the lower right of the screen and click. Clicking on any other place in the add-on box takes me to the proper screen.

Comment 6

[Gary [:streetwolf52]]

(In reply to Gary [:streetwolf52] from comment #5)

Just discovered something interesting. The address error only happen when I hover my pointer over the name of the add-on where it shows addons://detail/........ on the lower right of the screen and click. Clicking on any other place in the add-on box takes me to the proper screen.

I mean lower left of the screen.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

Jean-Yves, this sounds pretty serious? Can you set a severity on this bug?

Comment 8

[Jean-Yves Avenard [:jya]]

[delete]

Comment 9

[Jean-Yves Avenard [:jya]]

Installed the duckduck go security essential to play:
When you attempt to click; it wants to open: addons://detail/jid1-ZAdIEUB7XOzOJw@jetpack

which fails with:
[Parent 18584, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B0012 (NS_ERROR_UNKNOWN_PROTOCOL): file c:/Users/jyavenard/Work/Mozilla/gecko/netwerk/base/nsNetUtil.cpp, line 242
[Parent 18584, Main Thread] WARNING: NS_ENSURE_SUCCESS(aRv, false) failed with result 0x804B0012 (NS_ERROR_UNKNOWN_PROTOCOL): file c:/Users/jyavenard/Work/Mozilla/gecko/docshell/base/nsDocShell.cpp, line 9047
[Parent 18584: Main Thread]: V/DocumentChannel DocumentLoadListener DocumentChannelBridgeDisconnected [this=0000023B49C69740]
[Parent 18584: Main Thread]: V/DocumentChannel DocumentLoadListener dtor [this=0000023B49C69740]
[Parent 18584, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B0012 (NS_ERROR_UNKNOWN_PROTOCOL): file c:/Users/jyavenard/Work/Mozilla/gecko/docshell/base/nsDocShell.cpp, line 9795

which redirects to about:neterror?e=unknownProtocolFound&u=addons%3A//detail/jid1-ZAdIEUB7XOzOJw%40jetpack&c=UTF-8&d=Firefox%20doesn%E2%80%99t%20know%20how%20to%20open%20this%20address%2C%20because%20one%20of%20the%20following%20protocols%20%28addons%29%20isn%E2%80%99t%20associated%20with%20any%20program%20or%20is%20not%20allowed%20in%20this%20context.

Comment 10

[Jean-Yves Avenard [:jya]]

Why are we attempting to open an addon:// address via the parent document channel? What kind of URI are those.
:nika?

Comment 11

[Nika Layzell [:nika] (ni? for response)]

It looks like the "addons://" protocol is a fake protocol used in the aboutaddons.js script to name different views in the about:addons document. The URI doesn't seem to have any purpose other than as an a11y aid, and was added in bug 1567600 for that purpose: https://searchfox.org/mozilla-central/rev/0e09b9191c02097034e46b193930f91c45b7885d/toolkit/mozapps/extensions/content/aboutaddons.js#3191

The click event seems to be handled in the handleEvent method, and calls loadViewFn to load the given details view: https://searchfox.org/mozilla-central/rev/0e09b9191c02097034e46b193930f91c45b7885d/toolkit/mozapps/extensions/content/aboutaddons.js#2940. This then calls history.pushState to add a new history entry and loads the view. I don't see any code which would call preventDefault, or otherwise prevent the navigation. This makes me think that the navigation was always being started, and was just failing silently before.

I think this might actually be another instance of bug 1626362. The logic which decides which error pages to draw doesn't render unknown protocol error pages for page-triggered navigations (https://searchfox.org/mozilla-central/rev/0e09b9191c02097034e46b193930f91c45b7885d/docshell/base/nsDocShell.cpp#6103-6106), meaning that the previously loaded page continues to be displayed instead. However, DocumentChannel notices an error, and decides to change processes to a content process to display an error page, not realizing that no error page would be displayed.

Unlike bug 1626362, the process change switches enough state that this actually would cause the error page to be rendered, causing an error page to be displayed, rather than a broken tab.

The fix I suggested in my review for that bug might also fix the issue here: https://phabricator.services.mozilla.com/D79409?id=295381#inline-457514

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 13

[Mark Striemer [:mstriemer]]

This looks like a dupe of bug 1645286, which has a patch to fix the about:addons case.

Nika, is there more work to do here on this end or should this be duped to that bug?

Comment 14

[Gary [:streetwolf52]]

A little nit picking. The other bug report you mentioned is 5 days old. This bug report is 16 days old. Wouldn't you think that the other patch, which has a fix, should have been marked as a dup for this bug at it's creation? The point here is if it wasn't for the other bug report you would still be scratching your heads after 16 days. Seems the bug reporting process fell through a crack.

Comment 15

[Mark Striemer [:mstriemer]]

Yes, normally that one would be duped here but this bug was quickly moved out of the Add-ons Manager component and I missed it initially. Moving it did sort of makes sense since the regression wasn't from an Add-ons Manager change, but the fix there was small and ready before this was identified as a possible dupe.

Comment 16

[Nika Layzell [:nika] (ni? for response)]

(In reply to Mark Striemer [:mstriemer] from comment #13)

This looks like a dupe of bug 1645286, which has a patch to fix the about:addons case.

Nika, is there more work to do here on this end or should this be duped to that bug?

There's a platform bug which caused the underlying change in behaviour which I mention in comment 11, although I think we can track fixing that in bug 1626362 instead of tracking it here.