346561 - Always close useless tabs/windows opened for external handling

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect, P5)

Description

[Simon Bünzli]

We already do this for windows opened through target="_blank" and window.open(...). Why not also do it for windows/tabs opened through Shift+/Ctrl+click, middle-click, etc.?

Fixing this should be as simple as passing nsIWebNavigation::LOAD_FLAGS_NEW_WINDOW to all tabs on first load.

Comment 2

[Steffen Wilberg]

Bug 346851 renamed the flag to LOAD_FLAGS_FIRST_LOAD on trunk and 1.8 branch:
http://mxr.mozilla.org/seamonkey/source/docshell/base/nsIWebNavigation.idl#186

Comment 3

[Shawn Wilsher :sdwilsh]

(In reply to comment #0)
> Fixing this should be as simple as passing
> nsIWebNavigation::LOAD_FLAGS_NEW_WINDOW to all tabs on first load.
It's just a little bit more complicated than that, but I think I see what's up.

Comment 4

[Worcester12345]

See my comments in posts 29 and 83 about 'Disable Targets For Downloads' extension in Bug 241972 – new window opened by window.open('xxx.exe') or target="_blank" isn't closed automatically when a download begins .

Comment 5

[Akkana Peck]

> We already do this for windows opened through target="_blank" and
> window.open(...).

Does anyone know offhand where that code lives? It turns out that it's over-eager and sometimes closes windows that it didn't actually open (see related bug 394699).

I also mention it here because any fix for this bug (and it definitely is a bug -- I see those blank tabs all the time when middleclicking on links that turn out to be PDF) should also test that case, lest you accidentally exit the browser just by clicking on a link.

Comment 7

[ithinc]

This is not a solution, but a workaround working just as expected.

eval("gBrowser.mTabProgressListener = " + gBrowser.mTabProgressListener.toString().replace(/(?=var location)/, <![CDATA[
  if (aStatus == 0 && aWebProgress.DOMWindow.document.documentURI == "about:blank" && aRequest.QueryInterface(nsIChannel).URI.spec != "about:blank") {
    setTimeout(function(win) {win.close();}, 100, aWebProgress.DOMWindow);
  }
]]>));

Comment 8

[Amila indrajith]

I'm kind of new to the open source projects and I like to contribute here.I'm planning to work on this bug.Could someone help me to start things? where should I start from the code ? What kind of things I should know ?I'm very glad if someone can help me to sort out things.I already build the source code.

Comment 9

[Matthew N. [:MattN]]

Hi Amila, note that I think this bug may be non-trivial to fix.

Tim, is anyone on your team currently working on the external app handling stuff now? If so, is this bug on their radar to fix or could they mentor Amila?

Comment 10

[Amila indrajith]

Thanks, Matthew, It's my first time contributing open source project so I'm very glad if someone can guide me to solve this, please.

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Sean, is this something you could help Amila to figure out how it should work? Locate the code referenced in comment 0, and set the same flag on the Ctrl+click and middle-click call should make this work...

Comment 12

[Sean Lee [:seanlee][:weilonge]]

I am not familiar with these codes so far, but I still try to investigate this.

However, these codes [1] might be relative to the behavior for creating a new tab with Ctrl-Click/Cmd-Click.
The function nsWindowWatcher::OpenWindowInternal is executed when a link is clicked with Cmd-Click, so I suppose we could pass the flag LOAD_FLAGS_FIRST_LOAD in this function.

[1] https://dxr.mozilla.org/mozilla-central/source/embedding/components/windowwatcher/nsWindowWatcher.cpp#1063

Comment 13

[Amila indrajith]

thanks, Sean, I'm going to study on this but I'm a little bit confuse here.What should be the final output on this?

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Steps to reproduce:

1. Go to https://nightly.mozilla.org/
2. Use middle mouse button, click on the download button of any Firefox build

Actual result:

1. A new tab is opened, but the URL triggered a download dialog, leaving one tab stay at about:blank in the background.

Expected result:

1. Download dialog is triggered without leaving a blank tab in the background.

Comment 0, comment 1, and comment 12 have provided necessary hint to find the right flag to flip to enable this behavior.

Comment 15

[Amila indrajith]

Thanks, Tim,I'm crystal clear about the bug .I'll do my best.

Comment 16

[Amila indrajith]

(In reply to ithinc from comment #7)
> This is not a solution, but a workaround working just as expected.
> 
> eval("gBrowser.mTabProgressListener = " +
> gBrowser.mTabProgressListener.toString().replace(/(?=var location)/,
> <![CDATA[
>   if (aStatus == 0 && aWebProgress.DOMWindow.document.documentURI ==
> "about:blank" && aRequest.QueryInterface(nsIChannel).URI.spec !=
> "about:blank") {
>     setTimeout(function(win) {win.close();}, 100, aWebProgress.DOMWindow);
>   }
> ]]>));

Hi,
I'm trying to figure out where are these lines of the code ? But I didn't see anything similar to these,could you help me out?

Comment 18

[Mike Conley (:mconley) (:⚙️)]

This bug hasn't had activity in years. Going to close this as INCOMPLETE for now. Please re-open if new information becomes available.