Version: 4.5.0 (using KDE 4.5.0) OS: Linux After setting WebKit as the rendering engine, scroll on middle-click stopped working. With KHTML: when middle-clicking on a page, the pointer changes shape signaling the page can be scrolled. With KDE-WebKit KPart: when middle-clicking on a page, last entry in the clipboard history becomes an item entered in the address bar: if the item is a word, or a sentence, you get a google-search for them within the same page; if the item is a URL, the new page is loaded. Reproducible: Always OS: Linux (i686) release 2.6.32-24-generic Compiler: cc
Please report the webkit bugs to the appropriate component, not under konqueror.
OK, sorry. I will do that next time. Can you please explain me how to do that? The way I proceeded: I was having problems with Konqueror, so I clicked on "Report Bug", which brought me here: https://bugs.kde.org/enter_bug.cgi?format=guided&product=konqueror&additional_info=OS%3A%20Linux%20%28i686%29%20release%202.6.32-24-generic%0ACompiler%3A%20cc&version=4.5.00%20(KDE%204.5.0). At step 2, I read the components carefully, but could not find webkit, so I decided to leave the default. Many thanks in advance.
(In reply to comment #1) > Please report the webkit bugs to the appropriate component, not under > konqueror. (In reply to comment #2) > OK, sorry. I will do that next time. Can you please explain me how to do that? > > The way I proceeded: I was having problems with Konqueror, so I clicked on > "Report Bug", which brought me here: > https://bugs.kde.org/enter_bug.cgi?format=guided&product=konqueror&additional_info=OS%3A%20Linux%20%28i686%29%20release%202.6.32-24-generic%0ACompiler%3A%20cc&version=4.5.00%20(KDE%204.5.0). > At step 2, I read the components carefully, but could not find webkit, so I > decided to leave the default. Many thanks in advance. You do not need to worry about this. I have fixed it so that crashes will be reported to correct component going forward.
(In reply to comment #0) > Version: 4.5.0 (using KDE 4.5.0) > OS: Linux > > After setting WebKit as the rendering engine, scroll on middle-click stopped > working. > > With KHTML: when middle-clicking on a page, the pointer changes shape > signaling the page can be scrolled. > With KDE-WebKit KPart: when middle-clicking on a page, last entry in the > clipboard history becomes an item entered in the address bar: if the item is a > word, or a sentence, you get a google-search for them within the same page; if > the item is a URL, the new page is loaded. That cannot be correct. Both kwebkitpart and khtml should behave the so long as Konqueror's "Middle click opens url in selection" setting found under "Settings->WebBrowsing" is checked. The only difference should occur if that option is left off (unchecked) in which case kwebkitpart should not respond to middle clicks at all. In other words, the "move mouse vertically to scroll on middle click" feature is not yet implemented in kwebkitpart. However, your description here make it seem that kwebkitpart will always navigate to or search for content from the clipboard whenever the MMB is clicked. If this is not the case, please elaborate on how to duplicate the issue... As far as the other missing functionality. It is on the TODO list along with the "Smooth Scroll" functionality.
> That cannot be correct. Both kwebkitpart and khtml should behave the so > long as Konqueror's "Middle click opens url in selection" setting found > under "Settings->WebBrowsing" is checked. "Middle click opens URL in selection" was turned off intentionally in order to use middle-click to scroll pages vertically. But while this works normally with KHTML, it doesn't with kwebkitpart. > The only difference should occur > if that option is left off (unchecked) in which case kwebkitpart should > not respond to middle clicks at all. In other words, the "move mouse > vertically to scroll on middle click" feature is not yet implemented in > kwebkitpart. Now I see. Indeed, middle-click doesn't trigger the expected result (vertical scroll). However, although "Middle click opens URL in selection" is unchecked, middle-clicking with Webkit triggers a similar response nonetheless - I say "similar" because if last entry in the clipboard is a URL, rightclicking will open that URL within the tab. But if last entry in the clipboard is a word or a sentence: - with "Middle click opens URL in selection" checked on KHTML, I am asked "Do you want to search the Internet for [...]?"; - with the "Middle click opens URL in selection" UNchecked on Webkit, instead, middle-clicking will automatically show a page with results from Google. I believe this is not the intended behavior, since I did not initiate the search, but merely wanted to scroll the page vertically. According to your explanation, though, this feature is yet to be implemented, so it is my understanding that it should only fail to respond to any right-click, at that point. Hence, I believe this is not a feature request, but a bug that should be fixed. > However, your description here make it seem that kwebkitpart > will always navigate to or search for content from the clipboard whenever > the MMB is clicked. If this is not the case, please elaborate on how to > duplicate the issue... Sorry if my explanation sounds convoluted and lacks any technical knowledge, but if you feel it still fails to clarify the issue, please don't hesitate to let me know, and I will try to add any missing detail.
Errata corrige: "so it is my understanding that it should only fail to respond to any right-click, at that point" should read "so it is my understanding that it should only fail to respond to any middle-click, at that point". Sorry about that.
(In reply to comment #5) > > That cannot be correct. Both kwebkitpart and khtml should behave the so > > long as Konqueror's "Middle click opens url in selection" setting found > > under "Settings->WebBrowsing" is checked. > > "Middle click opens URL in selection" was turned off intentionally in order to > use middle-click to scroll pages vertically. But while this works normally > with KHTML, it doesn't with kwebkitpart. Ok. > > The only difference should occur > > if that option is left off (unchecked) in which case kwebkitpart should > > not respond to middle clicks at all. In other words, the "move mouse > > vertically to scroll on middle click" feature is not yet implemented in > > kwebkitpart. > > Now I see. Indeed, middle-click doesn't trigger the expected result (vertical > scroll). However, although "Middle click opens URL in selection" is unchecked, > middle-clicking with Webkit triggers a similar response nonetheless - I say > "similar" because if last entry in the clipboard is a URL, rightclicking will > open that URL within the tab. Huh ? Are we talking about middle clicking or right clicking ? Middle clicking whenever the above option is turned off should result in no action at all regardless of what is stored in the selection clipboard. The logic that is used in kwebkitpart is intended to prevent this from happening. > But if last entry in the clipboard is a word or a sentence: > > - with "Middle click opens URL in selection" checked on KHTML, I am asked "Do > you want to search the Internet for [...]?"; The prompt is missing in kwebkitpart and will be something that will be added for KDE 4.5.1 if allowed otherwise in KDE 4.6 (requires addition of a signal). > - with the "Middle click opens URL in selection" UNchecked on Webkit, instead, > middle-clicking will automatically show a page with results from Google. This should not happen and I am unable to duplicate it. It works correctly for me. If the option is not checked, I get nothing regardless of whether I have a url or regular text in the selection clipboard. > I believe this is not the intended behavior, since I did not initiate the > search, but merely wanted to scroll the page vertically. According to your > explanation, though, this feature is yet to be implemented, so it is my > understanding that it should only fail to respond to any right-click, at that > point. Hence, I believe this is not a feature request, but a bug that should > be fixed. > > However, your description here make it seem that kwebkitpart > > will always navigate to or search for content from the clipboard whenever > > the MMB is clicked. If this is not the case, please elaborate on how to > > duplicate the issue... Well that should not happen and indeed I cannot duplicate it on here on my system with KDE 4.5.0 and the 0.9.6 version of kwebkitpart. Out of curiosity can you please tell me what version of the kwebkitpart library is installed on your system ? You can find it by looking for "libkwebkit.so*" under /usr/lib. Unless you have a rather old version of kwebkitpart, I do not see how this bug can occur. > Sorry if my explanation sounds convoluted and lacks any technical knowledge, > but if you feel it still fails to clarify the issue, please don't hesitate to > let me know, and I will try to add any missing detail. No your explanation is perfectly fine. My response to it is based on the fact that I am unable to duplicate your problem.
> > Now I see. Indeed, middle-click doesn't trigger the expected result > > (vertical scroll). However, although "Middle click opens URL in > > selection" is unchecked, middle-clicking with Webkit triggers a similar > > response nonetheless - I say "similar" because if last entry in the > > clipboard is a URL, rightclicking will open that URL within the tab. > > Huh ? Are we talking about middle clicking or right clicking ? Middle-click, of course. Sorry, I really don't know where the "right" bit comes out from, I just mistyped. > > - with "Middle click opens URL in selection" checked on KHTML, I am asked > > "Do you want to search the Internet for [...]?"; > > The prompt is missing in kwebkitpart and will be something that will be > added for KDE 4.5.1 if allowed otherwise in KDE 4.6 (requires addition of > a signal). I see, this should explain that. > > I believe this is not the intended behavior, since I did not initiate the > > search, but merely wanted to scroll the page vertically. According to > > your explanation, though, this feature is yet to be implemented, so it > > is my understanding that it should only fail to respond to any > > right-click, at that point. Hence, I believe this is not a feature > > request, but a bug that should be fixed. > > Well that should not happen and indeed I cannot duplicate it on here on my > system with KDE 4.5.0 and the 0.9.6 version of kwebkitpart. Out of > curiosity can you please tell me what version of the kwebkitpart library > is installed on your system ? You can find it by looking for > "libkwebkit.so*" under /usr/lib. Unless you have a rather old version of > kwebkitpart, I do not see how this bug can occur. If I am correct, I only had to check the filename, and it says: libkwebkit.so.1.0.0. > > Sorry if my explanation sounds convoluted and lacks any technical > > knowledge, but if you feel it still fails to clarify the issue, please > > don't hesitate to let me know, and I will try to add any missing detail. > > No your explanation is perfectly fine. My response to it is based on the > fact that I am unable to duplicate your problem. It's OK, I thought it was a common problem, and I could contribute back to Konqueror after using it on a daily basis. Since it's mine alone, I'll switch back to KHTML for now, and give Webkit another try when Kubuntu Maverick is out. Many thanks for your assistance so far.
> > > - with "Middle click opens URL in selection" checked on KHTML, I am asked > > > "Do you want to search the Internet for [...]?"; > > > > The prompt is missing in kwebkitpart and will be something that will be > > added for KDE 4.5.1 if allowed otherwise in KDE 4.6 (requires addition of > > a signal). > I see, this should explain that. This is fixed now. You will get prompted before any searching is done just like KHTML. > > > I believe this is not the intended behavior, since I did not initiate the > > > search, but merely wanted to scroll the page vertically. According to > > > your explanation, though, this feature is yet to be implemented, so it > > > is my understanding that it should only fail to respond to any > > > right-click, at that point. Hence, I believe this is not a feature > > > request, but a bug that should be fixed. > > > > Well that should not happen and indeed I cannot duplicate it on here on my > > system with KDE 4.5.0 and the 0.9.6 version of kwebkitpart. Out of > > curiosity can you please tell me what version of the kwebkitpart library > > is installed on your system ? You can find it by looking for > > "libkwebkit.so*" under /usr/lib. Unless you have a rather old version of > > kwebkitpart, I do not see how this bug can occur. > If I am correct, I only had to check the filename, and it says: > libkwebkit.so.1.0.0. There lies in the problem... Unfortunately you have a rather old version of kwebkitpart. Because of some mishap the latest version should say 0.9.6 and not 1.0.0. Perhaps that is confusing the distro packagers and they are not updating it ?? No idea, but you can rest assured this works in the latest version minus the "automatic scrolling" feature of course. > > > Sorry if my explanation sounds convoluted and lacks any technical > > > knowledge, but if you feel it still fails to clarify the issue, please > > > don't hesitate to let me know, and I will try to add any missing detail. > > > > No your explanation is perfectly fine. My response to it is based on the > > fact that I am unable to duplicate your problem. > It's OK, I thought it was a common problem, and I could contribute back to > Konqueror after using it on a daily basis. Since it's mine alone, I'll switch > back to KHTML for now, and give Webkit another try when Kubuntu Maverick is > out. Many thanks for your assistance so far. No it is not yours alone. It seems to be a distro problem. If you can poke whomever is responsible to update the kwebkitpart package from extragear that would be great. They should use the latest version for KDE >= 4.4. Anyhow, thanks for your report. I will close this bug report, but would you be so kind to open a new wishlist item ticket for the unimplemented "automatic scrolling" feature so it won't be forgotten ? Thanks again.
> > > > - with "Middle click opens URL in selection" checked on KHTML, I am > > > > asked "Do you want to search the Internet for [...]?"; > > > > > > The prompt is missing in kwebkitpart and will be something that will be > > > added for KDE 4.5.1 if allowed otherwise in KDE 4.6 (requires addition > > > of a signal). > > > > I see, this should explain that. > > This is fixed now. You will get prompted before any searching is done just > like KHTML. Thanks for this! > > If I am correct, I only had to check the filename, and it says: > > libkwebkit.so.1.0.0. > > There lies in the problem... Unfortunately you have a rather old version of > kwebkitpart. Because of some mishap the latest version should say 0.9.6 and > not 1.0.0. Perhaps that is confusing the distro packagers and they are not > updating it ?? No idea, but you can rest assured this works in the latest > version minus the "automatic scrolling" feature of course. Alright, so that's why. At least this is fixable. > > It's OK, I thought it was a common problem, and I could contribute back > > to Konqueror after using it on a daily basis. Since it's mine alone, > > I'll switch back to KHTML for now, and give Webkit another try when > > Kubuntu Maverick is out. Many thanks for your assistance so far. > > No it is not yours alone. It seems to be a distro problem. If you can poke > whomever is responsible to update the kwebkitpart package from extragear > that would be great. They should use the latest version for KDE >= 4.4. OK, I will certainly try to! > Anyhow, thanks for your report. I will close this bug report, but would you > be so kind to open a new wishlist item ticket for the unimplemented > "automatic scrolling" feature so it won't be forgotten ? Thanks again. Done: https://bugs.kde.org/show_bug.cgi?id=247672. Many thanks for your support!