Closed Bug 1042280 Opened 10 years ago Closed 5 years ago

Can't force URLs on add-on pages to open within Firefox

Categories

(Thunderbird :: Add-Ons: General, defect)

Product:
Thunderbird
Component:
Add-Ons: General
Version:
45 Branch
Platform:
x86_64
Windows 8
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: educmale, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

just updated TBird from 30 to 31, which updated Lightning from 2.? to 3.3

I went to the add-on page, to see what the Lightning update/version was all about, and clicked on the provided URL.

I had these settings for HTTP and HTTPS, within the config:
   network.protocol-handler.warn-external.http ---> true
   network.protocol-handler.warn-external.https ---> true


Actual results:

Rather than opening within my Firefox, the item was opened within TBird as a new tab.

I added these two entries:
   network.protocol-handler.app.http ---> C:\Program Files (x86)\Mozilla Firefox\firefox.exe
   network.protocol-handler.app.https ---> C:\Program Files (x86)\Mozilla Firefox\firefox.exe
This does not correct the unexpected results.

Note: Clicking on a URL -within- an email properly refers to the page to Firefox, as expected


Expected results:

The URL found on the add-on page(s) should respect the choice to open within an external browser
I have a related or alternate question.
I have TBird set to check for update, but wait to update.   Clearly, TBird-31 makes the check whenever I open the About dialog box; this is new, and presumably this will fix other bugs where the check-for-updates went beyond that point to actually do the update without my permission.  

However, when else does TBird-31+ check for updates?   And when an update is detected, will TBird-31+ open a popup box to advise me ?
(In reply to john ruskin from comment #1)
> 
> However, when else does TBird-31+ check for updates?   And when an update is
> detected, will TBird-31+ open a popup box to advise me ?

Yes. On OS X, for example, there is even a notification at the Notification Center. I don't know how this is handled on other operating systems.
do you still see this issue when using a newer version?
Component: Untriaged → Preferences
Flags: needinfo?(educmale)
Yes.
Version: 31 Branch → 45 Branch
Flags: needinfo?(educmale)
duplicate?
Component: Preferences → Add-Ons: General
Severity: normal → minor

I would have thought this bug to be invalid. The decision was made to have add-on links in the application.

I'm using 60.9.0, currently, and the behavior continues as originally reported.

Reading Matt's comment #7...

I note, this: One of the theologies of the Fox browser is the ability to control privacy issues, mitigate against browser manipulation and more, either through direct programming, or add-on/extension choices, and the ability to treat URLs like, well, the fodder for browsers.

That entire universe doesn't exist inside T-Bird. Moreover, I can't even copy the URL inside T-Bird, with either a right click or a copy/paste with a mouse swipe (in fact, not that I need to, but nothing can be copied....). To get over to my browser of choice (Fox), one has to open the reference page, first, and then rely on the limited right clicks availed in T-Bird to copy links found there; there isn't a place on the T-Bird tab to copy the referenced page's URL. It would seem that -I- should have the choice to open the referenced link directly within the browser of my choice. I can't imagine that would be so difficult, given that the facility exists for URLs within emails, and that there are entries that [once, it seems] appeared to satisfy that choice.

I concur that this isn't a major bug, but it is a bug so long as T-Bird doesn't behave like a browser in all respect, from privacy to malignancy protection to general utility.

Perhaps Magnus can put this to rest

Flags: needinfo?(mkmelin+mozilla)

Not sure how those prefs work. But, Thunderbird will by default open links in your default browser. You're not supposed to set prefs to do it like that. Resetting the prefs will likely resolve the issue for you.

Flags: needinfo?(mkmelin+mozilla)

It's very unclear to me what links this bug is actually referring to, and where. However, it mentions an add-on page, so maybe it's pages on addons.thunderbird.net that load via the Add-on Manager.

Those are supposed to open in Thunderbird and I don't think the prefs affect that, because opening these links in the browser would be useless due to the fact that you can't install add-ons via the browser. There is no possible security issue opening add-on links in Thunderbird, either.

So if that's the type of link that this bug is referring to, this is a WONTFIX. But a screenshot or more specific description would help, given that this bug is 5 years old and many aspects of the UI have changed since then...

Good afternoon, all. Andrei is correct. The sources for the URLs are in several places, but begin with the Add-Ons Manager. For a particular extension, select "more", and a add-on manager page for a particular extensions is displayed. The URL, there , can not be opened in a Browser. I would have expected that a choice would be available on right-click, that was "open in browser".

The URL also appear on pages popped up by entering text into the search bar on the add-on manager. In all cases, the URLs open inside TBird. Unlike the URL mentioned in the above paragraph, one -can- right select a URL and open that URL within a browser. I do notice that links, found there, pointing outside of the mozilla domain, will open inside of the browser -- paypals, add-on home pages, etc., for example. I would wonder if there a possibility that these pages, the addon pages, will correctly enforce this so that there is not a possibility that a user will wander around the net, inside of the browser. I also wonder if there is a design protocol for the mozilla pages, which enforce this....

John, I still maintain that a decision was made that the links in the add-on manager would open in Thunderbird and the A.T.N site would operate within thunderbolt, limiting the add-ons to only those that would execute in your version and getting away from the very long standing question of "what do I do with this XPI file, I double click it and it does nothing" by managing installs and updates.

Magnus says that there are preferences that can force those links to open in a browser. Perhaps there are. In which case this bug is invalid. If there are not options, I still think the bug is invalid as the developers intended addon links within the add-on manager to open in the application, so Thunderbird is operating as intended.

However, I note that you can right click all the links in the search for new add-ons and select open in browser, it is only installed addons that do not have a standardised "hyperlink" right click menu.

Clicking on links in the "header" of A.T.N pages for things like "Extensions", "Themes", "collections Log in etc all open links in a browser.

So would it be reasonable to assume this bug is about forcing links in installed addons to open in your browser. Those links appear to be.

The link to "more" information on the installed add-on.
The link on the authors name
The add-on home page
Links to the add-ons reviews.

I really do not think those are an accident but I think it is important to define the scope of your request. I limit it to those four things because I can not make Thunderbird open anything else internally.

(In reply to john from comment #12)

I do notice that links, found there, pointing outside of the mozilla domain, will open inside of the browser -- paypals, add-on home pages, etc., for example. I would wonder if there a possibility that these pages, the addon pages, will correctly enforce this so that there is not a possibility that a user will wander around the net, inside of the browser.

Only links on addons.thunderbird.net should open inside Thunderbird. If no other links open inside Thunderbird, this is WONTFIX imo.

Indeed.

The prefs I mentioned earlier would only do anything for other urls, not things inside the add-on manager.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX

Only links on addons.thunderbird.net should open inside Thunderbird. If no other links open inside Thunderbird, this is WONTFIX imo.

There are other links, so this issue should be reopened.

To reproduce, I have enigmail installed, and I clicked "Tools -- Add-ons", then opened "More" for "Enigmail", and then in the "Homepage" row clicked the link. That opened the enigmail homepage in Thunderbird. As that homepage is certainly not part of the TB UI, and in geneneral an arbitrary website, I strongly feel it should be opened in the browser and not treated as "belonging to" Thunderbird.

My understand of what Adrei said is that this is NOT wontfix (but there are double-negations here so I might be confused). Can someone reopen this issues or should I open a new issue about this?

To reproduce, I have enigmail installed, and I clicked "Tools -- Add-ons", then opened "More" for "Enigmail", and then in the "Homepage" row clicked the link. That opened the enigmail homepage in Thunderbird. As that homepage is certainly not part of the TB UI, and in geneneral an arbitrary website, I strongly feel it should be opened in the browser and not treated as "belonging to" Thunderbird.

Yeah, this sounds like a bug to me. I note that this doesn't happen when you go to the enigmail page on ATN, it only happens within the Addons Manager itself. I think this should be filed as a separate bug, as this bug is not specific enough and it should not depend on your settings.

See: Bug 1587132

See Also: → 1587132

For me the homepage link just opens in Firefox. I do have network.protocol-handler.expose.http and network.protocol-handler.expose.https toggled to false, no other related http prefs, but I think this behavior might have changed in TB68, to also make it possible to make the donation link work again, bug 1500895.

Those two settings are still at the default for me, which using TB 60.9.0 means they are both true.

You need to log in before you can comment on or make changes to this bug.