> On Nov. 22, 2012, 11:04 a.m., David Faure wrote: > > Well, if setFocus() shouldn't trigger the PartManager, then the fix would > > be in PartManager itself. Otherwise the part manager and konqueror will > > have a different vision of the currently active part. > > > > In order to avoid breaking other apps that use PartManager (if any), I > > would suggest to add a setter in PartManager, something like > > setIgnoreExplicitSetFocus(true). > > > > In addition, this patch (whether it's done in konq or kparts) requires > > changing some code in Konqueror, where setFocus() was assumed to end up > > calling setActivePart. > > 1) there's a comment in konqviewmanager.cpp:1062 about that, but the > > comment can simply be adjusted (this was an unnecessary recursive call, so > > removing that is no problem) > > 2) there's a setFocus in konqmainwindow.cpp:4778 whose purpose was > > precisely to set the current part back to what it was before the RMB popup > > was opened. With this change, setFocus doesn't trigger a setActivePart > > anymore, so an explicit call to setActivePart should be added. > > > > Looking at the other setFocus calls: > > * KonqView::setLoading calls setFocus, but it's ok if this doesn't change > > the active part (fixes a race condition with the user changing parts > > quickly after starting to load a typed url, so that's fine) > >
Ok. I am working on correcting the original fix for this. Should I aim the fix for 4.10 or 4.9.5 since it is actually a bug fix (technically a fix for a bug fix) ? I would guess 4.10 makes more sense at this point since the fix requires the addition of a new member function to KParts::PartManager. Also I am unsure what you meant for the comment in konqviewmanager.cpp. Do you want to change the comment or remove the setFocus call itself ? - Dawit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107048/#review22370 ----------------------------------------------------------- On Oct. 30, 2012, 7:49 p.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107048/ > ----------------------------------------------------------- > > (Updated Oct. 30, 2012, 7:49 p.m.) > > > Review request for KDE Base Apps and David Faure. > > > Description > ------- > > The attached patch is an attempt to fix the bug where opening certain types > of documents in a background tab results in the new tab being activated > inadvertently. > > The issue can be reproduced by simply attempting to open a PDF document using > either the MMB or the CTRL+LMB button in Konqueror. If you have a local PDF > file simply navigate to the location of the file and click on it using the > MMB. Otherwise, see the aforementioned bug report for a site with PDF links > in it. If the "Open new tabs in background" option is checked when you > clicked on the PDF document, then the PDF document is opened embedded in > Konqueror tab in the background. However, this background tab should not be > activated when the aforementioned option is enabled. > > Unfortunately, in the currently implementation the background tab will get > activated if the part used to handle the resource (PDF file in this case) > issues a FocusIn event, for example by calling setFocus. That is because > KPart::PartManager installs an event filter on all the KParts it manages, > listens for FocusIn events, and invokes KParts::PartManager::setActivatePart. > > > This addresses bug 306417. > http://bugs.kde.org/show_bug.cgi?id=306417 > > > Diffs > ----- > > konqueror/src/konqviewmanager.cpp c8e3cb0 > > Diff: http://git.reviewboard.kde.org/r/107048/diff/ > > > Testing > ------- > > - Tested opening a PDF file when the "Open new tabs in background" option is > checked. > - Tested opening a PDF file when the "Open new tabs in background" option is > UNchecked. > - Tested opening a PDF link from a webpage using both the MMB and CTRL+LMB. > > > Thanks, > > Dawit Alemayehu > >
