At some point Kparts plugin which I use to view PDFs in Firefox (10.0.2) started behaving strangely. Instead of opening inside Firefox tab it pops out a separate titleless window where it loads PDF content. What triggers that mode, and how can it be docked back inside the browser?

Can you reproduce this in Konqueror, or under a new user?

Just tested, in Konqueror (primary user) as well as for a new testing Linux user (using Firefox) the plugin is displayed inside the browser. However even for another Firefox profile and primary user, the problem persists. Looks like some kind of persistent plugin specific setting (not related to the Firefox profiles). I'm using kpartsplugin package on Debian testing.

Can you check in about:plugins and compare the two between both users?

Primary user:

Code: Select all

KParts Plugin

    File: libkpartsplugin.so
    Version:
    File viewer using KDE's KParts technology (2011-08-23)


Plus huge list of associated mime types.

Same thing for the testing user. I'll make the diff between the two just in case.

Okay, try running "kbuildsycoca4 --noincremental" to flush the list of associations and rebuild it.

It ran, producing bunch of messages like:

Code: Select all

Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kbuildsycoca4 running...
kbuildsycoca4(8946) KConfigGroup::readXdgListEntry: List entry Actions in "ScreenSavers/helios.desktop" is not compliant with XDG standard (missing trailing semicolon).


Restarted Firefox. That didn't affect the plugin behavior though.

Just to note, the external window is not a normal Okular. It has the same controls as a docked plugin inside the browser. But it's opened in a separate window. The tab which supposed to hold the plugin is left without any content (transparent).

I even tried to uninstall and reinstall the plugin - the issue didn't go away.

Okay, it looks like it is failing to embed itself into Firefox - for unknown reasons. Your best bet is to look for a file named "mozillarc", "firefoxrc" or "kpartspluginrc" (or similar) under ~/.kde*/

If you are unsure about which files to delete, please ask here.

The only related file seems to be okularpartrc. I moved it out temporarily, it was created anew, but it didn't change the buggy behavior. I suspect it's some weird global settings for that window which was triggered accidentally by some key combination or something of that sort. Temporarily moving out all files from ${HOME}/.kde/share/config and starting Firefox solves this problem. I'll try to narrow down to what exactly is the culprit setting.

Key suspects would be kdeglobals.

Given that you did not restart KWin, kwinrc is likely not at fault, and neither is plasma* (plasmarc, plasma-desktoprc, plasma-desktop-appletsrc) as you did not restart Plasma Desktop either.

Best way to test would be by moving config files back one by one. It is likely safe to move all <appname>rc files back however - as they should only affect those applications and not others.

kdeglobals is referenced and loaded by all KDE applications.

I found the offending setting. Strangely, it's in ~/.kde/share/config/oxygenrc

[Common]
BackgroundOpacity=211
OpacityBlackList=bangarang,dragon,kaffeine,kdenlive,kwin,lancelot,loopy,nspluginviewer,smplayer
OpacityGreyList=amarok,bangarang,dragon,kaffeine,kdenlive,krunner,kscreenlocker,kwin,lancelot,loopy,nspluginviewer,smplayer,vlc,vlc-wrapper

[Windeco]
BlendColor=Radial Gradient

[Windeco Exception 0]
BlendColor=Solid Color
Enabled=true
Mask=32
Pattern=(Firefox)|(Thunderbird)|(Gimp)
Type=Window Class Name

The offending setting is BackgroundOpacity=211. When that line is removed, this docking bug goes away. I suspect it has something to do with me using oxygen-transparent and related issues. May be I need to blacklist kpartsplugin or okular somehow?

Filed a bug: https://bugs.kde.org/show_bug.cgi?id=299690

There is a fix now for the latest version of Kpartsplugin: https://bugs.kde.org/show_bug.cgi?id=299690#c3