| Summary: | Konqueror opens a new, empty tab in some cases | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | András Manţia <amantia> |
| Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | anderslund, faure, gassauer, maksim |
| Priority: | NOR | ||
| Version: | SVN | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
András Manţia
2008-09-14 11:48:20 UTC
Please let me know if you can find a way to reproduce it. I suspect I know what it is (double-click events getting propagated up to the tabwidget) but I would like a way of testing before making the change. Fixed in r861259. Let's reopen it as I can give an example for the "pdf" part: http://www.insse.ro/cms/rw/pages/comunicate/arhivasomaj.en.do click on any link that contains a pdf. A new tab "Loading" will appear and a dialog asks you to open the file in okular or save it. Whatever you chose, the Loading tab will stay there until you close it. Can't fix. If we don't open the tab immediately, konqueror appears unresponsive (been there, tried that, see Bug 163628). So we have to open the tab immediately, even if we (in rare cases) are not going to use it because we are firing another application instead. There is no choice there. Try it in Firefox, it does exactly the same: you get a "Loading" tab, that ends up being unused. And cleaning up the unused tab automatically would lead to unexpected jumping behavior, confusing users when they are about to close the tab or type a new url or switch tabs etc. Firefox indeed opens the new tab, but closes as soon as the dialog to choose the application that opens the file appears. OK, I guess that doing it when popping up the dialog (just before, or even better, just after) is a way to avoid the race where the user would be clicking on the "close tab" button just after we delete the tab (and therefore closing another unrelated tab). This seems like a good solution. Reopening (but no time for this right now). *** Bug 172923 has been marked as a duplicate of this bug. *** Git commit ccf74eaa8c9ab1807848272e065562414ff278c5 by Dawit Alemayehu. Committed on 07/09/2011 at 08:15. Pushed by adawit into branch 'master'. Automatically close empty new windows created through a JS call whenever the request is handled by external application. CCBUG: 171029 M +4 -0 src/webpage.cpp http://commits.kde.org/kwebkitpart/ccf74eaa8c9ab1807848272e065562414ff278c5 Git commit fcaac497dc1282f6f019c120b06659a72f8a543b by Dawit Alemayehu. Committed on 07/09/2011 at 08:15. Pushed by adawit into branch '1.2'. Automatically close empty new windows created through a JS call whenever the request is handled by external application. CCBUG: 171029 M +4 -0 src/webpage.cpp http://commits.kde.org/kwebkitpart/fcaac497dc1282f6f019c120b06659a72f8a543b Git commit 06892ce6e5bb920e9b586f60f7ace2da745ef2cd by Dawit Alemayehu. Committed on 07/09/2011 at 08:15. Pushed by adawit into branch 'master'. Automatically close empty new windows created through a JS call whenever the request is handled by external application. CCBUG: 171029 (cherry picked from commit fcaac497dc1282f6f019c120b06659a72f8a543b) M +4 -0 src/webpage.cpp http://commits.kde.org/kwebkitpart/06892ce6e5bb920e9b586f60f7ace2da745ef2cd *** Bug 259361 has been marked as a duplicate of this bug. *** |