Closed Bug 346561 Opened 18 years ago Closed 4 years ago

Always close useless tabs/windows opened for external handling

Categories

(Firefox :: General, defect, P5)

defect

Tracking

()

RESOLVED INCOMPLETE
Future

People

(Reporter: zeniko, Unassigned, NeedInfo)

References

(Blocks 2 open bugs)

Details

(Keywords: polish, 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.
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
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)

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

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.