| Summary: | Links to pdf and other file types are opened in an html embed frame | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] kwebkitpart | Reporter: | Grósz Dániel <groszdanielpub> |
| Component: | general | Assignee: | webkit-devel |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | adawit |
| Priority: | NOR | ||
| Version: | 1.3.1 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Grósz Dániel
2013-10-12 19:34:04 UTC
Note that this behavior does not happen if the link is opened in a new tab. The fact that the link you click to leads to a HTML page with an embeded PDF document is an issue of the server. Not the client. We render whatever the server sends back. Nothing we can do about that. The remaining stuff is not a bug. It is intentional. When a document is embedded into a web page, we are not going to show you the controls for that part because you are still viewing an html page with embedded document. For the same reasoning we do not show you the controls for the flash viewer when you see embedded flash video or HTML 5 audio/video. Only built-in controls are available. The frame has the same code with many different servers. I find it unlikely that they all send this kind of frame. Examples: http://dot.kde.org/2013/09/04/kde-release-structure-evolves Click on the chart with the libraries. Even directory listings such as http://groszdani.web.elte.hu/tmp/ (click on a pdf or tex file). I checked the network traffic with wireshark and it does not show this frame code. Another observation: for some files such as .log and .aux files in the directory listing, a different frame appears: the file is enclosed between <html><head></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;"> and </pre></body></html> Again, no trace in wireshark. If I refresh the page, it appears notmally in katepart. (In reply to comment #3) > The frame has the same code with many different servers. I find it unlikely > that they all send this kind of frame. > Examples: > http://dot.kde.org/2013/09/04/kde-release-structure-evolves Click on the > chart with the libraries. By chart I assume you mean the PNG image and in that case webkit and khtml differ on how they handle it. This is true for text files as well. WebKit and by extension QtWebKit has a built-in viewer for text files and images. QtWebKit does not provide a means for us to prevent it from using these builtin viewers. So if you click on an image or a text file link, then it is going to be shown using the built-in viewer. If you want to view it with something else you have to right click on the image/text link and choose another application to open it with. I opened a request to have the ability to change that upstream, but nothing In KHTML on the other hand the image is correctly based on the preferences set in your fileassociations dialog ; so you might want to check that. > Even directory listings such as http://groszdani.web.elte.hu/tmp/ (click on a pdf or tex file). > I checked the network traffic with wireshark and it does not show this frame code. This works correctly for me because does not natively handle QtWebkit cannot handle these kind of mime-types. If I click on a tex or a pdf link, I correctly get prompted with a open or save dialog. If your desktop is configured to show the document in an embedded viewer, then it should correctly show the document embedded with the correct part. If that is not the case, then perhaps you have some sort of plugin wrapper, like nspluginwrapper, is installed on your system and that might be what is causing this issue for you. My system is configured to open pdf files in an embedded viewer. But even if I change the configuration to open them in a separate viewer, clicking on a pdf link in webkit will still open it in a html frame in Konqueror. (However it will not try to open xls or doc files in Konqueror, which have no kpart that could open them.) Deinstalling nspluginwrapper does not change anything. However if I uncheck Enable plugins globally, it opens all files in separate applications. (Even though disabling plugins does not otherwise prevent Konqueror from using kparts: if I type a pdf url in the location bar, or click on a pdf file in the dolphin part, it will open within Konqueror if pdf files are configured to open in an embedded viewer.) As for image and text files: Konqueror does know that a link is opened since the Location bar reflects the URL change. At that point it could switch to the appropriate kpart. I don't know if that's feasible and/or desirable. Actually if I press Refresh when a text/image file is opened, it switches to the appropriate kpart. (In reply to comment #7) > As for image and text files: Konqueror does know that a link is opened since > the Location bar reflects the URL change. At that point it could switch to > the appropriate kpart. I don't know if that's feasible and/or desirable. > > Actually if I press Refresh when a text/image file is opened, it switches to > the appropriate kpart. Please note that clicking on the link and entering it in Konqueror's bar or refreshing it from Konqueror are not the same action. The click is handled by QtWebKit where as the refresh/load are handled by Konqueror. That is why load/reload or refresh will result in the url being opened by the configured part. As I said this is a known issue, but there is nothing we can do about fixing it since QtWebKit does not allow us to override its setting. See https://bugs.webkit.org/show_bug.cgi?id=51292. (In reply to comment #6) > My system is configured to open pdf files in an embedded viewer. But even if > I change the configuration to open them in a separate viewer, clicking on a > pdf link in webkit will still open it in a html frame in Konqueror. (However > it will not try to open xls or doc files in Konqueror, which have no kpart > that could open them.) > > Deinstalling nspluginwrapper does not change anything. However if I uncheck > Enable plugins globally, it opens all files in separate applications. (Even > though disabling plugins does not otherwise prevent Konqueror from using > kparts: if I type a pdf url in the location bar, or click on a pdf file in > the dolphin part, it will open within Konqueror if pdf files are configured > to open in an embedded viewer.) Right. You answered your own issue here. If you disable nsplugin globally the problem goes away. That means there is another plugin installed that supports showing pdf content ; so this is caused by same exact issue as bug 35940. There is another plugin screwing things up. > Right. You answered your own issue here. If you disable nsplugin globally
> the problem goes away. That means there is another plugin installed that
> supports showing pdf content ; so this is caused by same exact issue as bug
> 35940. There is another plugin screwing things up.
Now I removed the only directory that contains any plugins (/usr/lib64/browser-plugins) from the plugin folder list and clicked Scan plugins. So now I have plugins enabled globally, but I don't actually have any plugin. The problem still persists, unlike if I disable plugins globally.
If I uncheck Enable plugins globally, another problem arises: files are opened in separate applications even if they are configured to be opened in an embedded kpart.
Is unchecking Enable plugins globally actually supposed to disable kparts too, or only netscape plugins?
(In reply to comment #10) > > Right. You answered your own issue here. If you disable nsplugin globally > > the problem goes away. That means there is another plugin installed that > > supports showing pdf content ; so this is caused by same exact issue as bug > > 35940. There is another plugin screwing things up. > > Now I removed the only directory that contains any plugins > (/usr/lib64/browser-plugins) from the plugin folder list and clicked Scan > plugins. So now I have plugins enabled globally, but I don't actually have > any plugin. The problem still persists, unlike if I disable plugins globally. Unfortunately removing the path from the plugin configuration dialog will have no effect because the plugins causing the problem are still present on your system. QtWebKit's plugin path scanner has its own hardcoded list of path it will check and does not allow those paths to be externally modified as far as I know. Hence, unless you remove the offending plugin, QtWebKit's plugin scanner will always find it and you would still have this problem. > If I uncheck Enable plugins globally, another problem arises: files are > opened in separate applications even if they are configured to be opened in > an embedded kpart. This is actually a problem with the kwebkitpart because the KPart integration is rather very difficult for a number of reasons. I will look into this issue because I can reproduce this problem. > Is unchecking Enable plugins globally actually supposed to disable kparts > too, or only netscape plugins? Only netscape plugins. > Unfortunately removing the path from the plugin configuration dialog will
> have no effect because the plugins causing the problem are still present on
> your system. QtWebKit's plugin path scanner has its own hardcoded list of
> path it will check and does not allow those paths to be externally modified
> as far as I know. Hence, unless you remove the offending plugin, QtWebKit's
> plugin scanner will always find it and you would still have this problem.
As I said, I also tried removing the nspluginwrapper. Anyway, now I manually removed all files in the browser-plugins directory and restarted Konqueror, and the problem persists.
(In reply to comment #12) > > Unfortunately removing the path from the plugin configuration dialog will > > have no effect because the plugins causing the problem are still present on > > your system. QtWebKit's plugin path scanner has its own hardcoded list of > > path it will check and does not allow those paths to be externally modified > > as far as I know. Hence, unless you remove the offending plugin, QtWebKit's > > plugin scanner will always find it and you would still have this problem. > > As I said, I also tried removing the nspluginwrapper. Anyway, now I manually > removed all files in the browser-plugins directory and restarted Konqueror, > and the problem persists. Then I cannot help you since I cannot reproduce the problem with stock KDE and the only adobe's flash player plugin installed from my distro (ArchLinux). You might want to report it that to your distro, but I doubt they would care if Konqueror or reKonq or for that matter any small market browser is not working correctly. After all that is why they install all that crap as a dependency by default. Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone! Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |