Always close useless tabs/windows opened for external handling

NEW
Unassigned

Status

()

defect
P5
normal
13 years ago
2 years ago

People

(Reporter: zeniko, Unassigned, NeedInfo)

Tracking

(Blocks 2 bugs, {polish})

unspecified
Future
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +
blocking-firefox3 -
wanted-firefox3 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: p=0)

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.
Duplicate of this bug: 374917
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
Flags: blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3+
Keywords: polish
Assignee: nobody → sdwilsh
Target Milestone: --- → Firefox 3 alpha6
(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.

Status: NEW → ASSIGNED
Depends on: 382383
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 .
Target Milestone: Firefox 3 alpha6 → Firefox 3 beta1
Target Milestone: Firefox 3 M7 → Firefox 3 M9
> 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.
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Priority: -- → P5
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
Target Milestone: Firefox 3 Mx → Firefox 3 M11
Assignee: sdwilsh → nobody
Status: ASSIGNED → NEW
Target Milestone: Firefox 3 beta3 → Future
Blocks: 565553
No longer blocks: 565553
Duplicate of this bug: 565553
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);
  }
]]>));
Blocks: fxdesktopbacklog
No longer blocks: fxdesktoptriage
Whiteboard: p=0
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
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.
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?
Flags: needinfo?(timdream)
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.
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...
Flags: needinfo?(timdream) → needinfo?(selee)
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
Flags: needinfo?(selee)
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?
Flags: needinfo?(timdream)
Flags: needinfo?(selee)
Flags: needinfo?(MattN+bmo)
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.
Flags: needinfo?(timdream)
Flags: needinfo?(selee)
Flags: needinfo?(MattN+bmo)
Thanks, Tim,I'm crystal clear about the bug .I'll do my best.
(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?
Flags: needinfo?(tabutils+bugzilla)
Duplicate of this bug: 1344681
You need to log in before you can comment on or make changes to this bug.