Created attachment 45643[details]
Qt 4.5.3 Windows Java 1.6.0u17 Applet patch by John Spicer
This bug is hereby created to track progress towards adding Java Applet support to Qt Webkit.
Attached you will find a very basic, barely functional patch against the WebKit version shipped with Qt 4.5.3* on Windows.
It requires Sun's Java Plugin2 capability be available on the machine running WebKit, so it works with 1.6.0u17 (not sure if earlier versions of Java work).
Feeble attempts made by myself and John to port this to 4.6.0 have failed. Girish Ramakrishnan has said he'll take a peek at this early in the new year.
TODO:
- port to 4.6.0
- port to OSX, Linux and beyond!
- test, test, test
- things that don't work:
1. applets loaded as .class such as http://javatester.org/version.html [ applets in .jar files such as http://java.com/en/download/installed.jsp?detect=jre&try=1 do work! :D ]
2. running on anything other then windows
3. ???
* = Qt 4.5.3's WebKit version is [ git://gitorious.org/qtwebkit/qtwebkit.git --- commit imported from: origin/qtwebkit-4.5 branch/tag --- sha1 checksum: eb3afcbfb4006de4015047555cb256fcde93b954 ] that works

Created attachment 47837[details]
Qt 4.5.3 Windows Java 1.6.0u17 Applet patch -- Updated: Feb 1, 2010
@Kenneth
Here is the the patch run through check-webkit-style and with qDebug()'s replaced with LOG statements (hoping that is the right thing to replace qDebug's with). Note: I did not fix all of the check-webkit-style issues for the class, there are numerous issues that were present in the original classes, I just made sure any new code does not add to the check-webkit-style issues list...
@Girish
patching file src/3rdparty/webkit/WebCore/plugins/win/PluginDatabaseWin.cpp
Hunk #1 succeeded at 463 with fuzz 2 (offset 138 lines).
Hunk #2 FAILED at 535.
1 out of 2 hunks FAILED -- saving rejects to file src/3rdparty/webkit/WebCore/plugins/win/PluginDatabaseWin.cpp.rej
patching file src/3rdparty/webkit/WebCore/plugins/win/PluginPackageWin.cpp
Hunk #1 FAILED at 223.
1 out of 1 hunk FAILED -- saving rejects to file src/3rdparty/webkit/WebCore/plugins/win/PluginPackageWin.cpp.rej
patching file src/3rdparty/webkit/WebKit/qt/WebCoreSupport/FrameLoaderClientQt.cpp
Hunk #1 succeeded at 1215 with fuzz 1 (offset 139 lines).
Hunk #2 succeeded at 1305 with fuzz 2 (offset 157 lines).
Hunk #3 FAILED at 1314.
1 out of 3 hunks FAILED -- saving rejects to file src/3rdparty/webkit/WebKit/qt/WebCoreSupport/FrameLoaderClientQt.cpp.rej

(In reply to comment #3)
> @Kenneth
> Here is the the patch run through check-webkit-style and with qDebug()'s
> replaced with LOG statements (hoping that is the right thing to replace
> qDebug's with). Note: I did not fix all of the check-webkit-style issues for
> the class, there are numerous issues that were present in the original classes,
> I just made sure any new code does not add to the check-webkit-style issues
> list...
That is why you can make check-webkit-style only check what you changed and not the file itself. Please check its arguments. If you use git you can do
check-webkit-style --git-index=<GIT-HASH>

(In reply to comment #4)
> (In reply to comment #3)
> > @Kenneth
> > Here is the the patch run through check-webkit-style and with qDebug()'s
> > replaced with LOG statements (hoping that is the right thing to replace
> > qDebug's with). Note: I did not fix all of the check-webkit-style issues for
> > the class, there are numerous issues that were present in the original classes,
> > I just made sure any new code does not add to the check-webkit-style issues
> > list...
>
> That is why you can make check-webkit-style only check what you changed and not
> the file itself. Please check its arguments. If you use git you can do
>
> check-webkit-style --git-index=<GIT-HASH>
~/mnt/qtwebkit/WebKitTools/Scripts/check-webkit-style --git-index=eb3afcbfb4006de4015047555cb256fcde93b954 FrameLoaderClientQt.cpp
Syntax: check-webkit-style [--verbose=#] [--git-commit=<SingleCommit>] [--output=vs7]
[--filter=-x,+y,...] [file] ...
It doesn't matter anyway, there weren't that many style violations to track them by hand looking by running check-webkit-style against the original and then the new.

> ~/mnt/qtwebkit/WebKitTools/Scripts/check-webkit-style
> --git-index=eb3afcbfb4006de4015047555cb256fcde93b954 FrameLoaderClientQt.cpp
>
> Syntax: check-webkit-style [--verbose=#] [--git-commit=<SingleCommit>]
> [--output=vs7]
> [--filter=-x,+y,...] [file] ...
>
> It doesn't matter anyway, there weren't that many style violations to track
> them by hand looking by running check-webkit-style against the original and
> then the new.
Ah sorry, use --git-commit=<hash>, it is prepare-ChangeLog which has --git-index

(In reply to comment #6)
> Ah sorry, use --git-commit=<hash>, it is prepare-ChangeLog which has
> --git-index
No worries, I tried that one also... Perhaps I used it wrong, or perhaps it doesn't work because the WebKit source tree that is shipped with the Qt 4.5.3 source is an export and not actually under Git.
~/mnt/qtwebkit/WebKitTools/Scripts/check-webkit-style --git-commit=eb3afcbfb4006de4015047555cb256fcde93b954 FrameLoaderClientQt.cpp
ERROR: It is not possible to check files and a specific commit at the same time.

> ~/mnt/qtwebkit/WebKitTools/Scripts/check-webkit-style
> --git-commit=eb3afcbfb4006de4015047555cb256fcde93b954 FrameLoaderClientQt.cpp
> ERROR: It is not possible to check files and a specific commit at the same
> time.
The check-webkit-style told you exactly what you did wrong, please leave our the file argument
check-webkit-style --git-commit=eb3afcbfb4006de4015047555cb256fcde93b954

(In reply to comment #8)
> The check-webkit-style told you exactly what you did wrong, please leave our
> the file argument
>
> check-webkit-style --git-commit=eb3afcbfb4006de4015047555cb256fcde93b954
~/mnt/qtwebkit/WebKitTools/Scripts/check-webkit-style --git-commit=eb3afcbfb4006de4015047555cb256fcde93b954
fatal: Not a git repository (or any of the parent directories): .git
Right so it fails because as I mentioned it's an export of the source and not actual Git tree.

I know building Qt from scratch can be painfully slow, so I've posted my applet-segfaulting build of Qt 4.6.2 for Windows.
It is available at: http://www.northern.ca/projects/qt/Qt4.6.2-E-Drive-2010-02-19.zip (1.5 GB)
Notes:
* It includes the Qt 4.6.2 Java Applet patch which currently causes segfaults when applets start
* Qt Debug Target's WebKit libraries are built with full debugging symbols (CFLAGS,CXXFLAGS = -g ... )
* It has a custom builder batch file (E:\qt\build-qt.cmd) to help facilitate building/rebuilding and includes SSL libraries.

Created attachment 51212[details]
patch against the QtWebKit week9 / week10, fixes the seg fault by reverting the NPAPI API minor number - Note it works on Windows, but returns a blue plug-in brick on OSX
The seg fault is caused by the commit:
Anders Carlsson <andersca@apple.com> 2009-02-05 15:58:34 (sha1 3e01afdf183c8248ed49e9ba8c27573c470a19ca)
The NP_VERSION_MINOR version number from 20 to 23 and in a later commit to 24 (sha1 dd28484e008819aa59c5549a703ecee8bcbe4f22).
In c0baac9e0ae1ed075e2ff78b4bbe0d1b6872cb35, an Objective-C implementation for NPN_GetValueForURL, NPN_SetValueForURL() and NPN_GetAuthenticationInfo() would be committed to ./WebKit/mac/Plugins/npapi.mm, but no corresponding C++ implementation of those methods was added to ./WebCore/plugins/npapi.cpp.
What this means is when QtWebKit starts Java or any other NPAPI plug-in it returns an NPVersion value for an API level (Gecko NPAPI v1.9) that it does not completely implement. When Java tries to invoke those unimplemented callback methods, everything seg faults and you are left with a worthless stack of Java/Kernel threads with no debug info at all.
To get around this the attached patch, in addition to enabling Java, reverts the NP_VERSION_MINOR back to 20, which tells Java not to invoke the unimplemented callbacks.

Created attachment 51265[details]
patch against the QtWebKit week11, requires the NPN_(Get/Set)ValueForURL patch attached to #34539
This patch requires https://bugs.webkit.org/attachment.cgi?id=51264
\-> This patch has the required Gecko NPAPI v1.9 methods in crude working form. i.e. Is there a non-Qt way to figure out proxy settings that WebKit is using to provide that to the plugin?
Feel free to improve the patches!

I do not know about the Windows related change, but on Linux the one line patch in FrameLoaderClientQt::createJavaAppletWidget is sufficent to activate the Java applet support in QtWebKit granted the patch in bug# 34539 is also applied.

(In reply to comment #20)
> I do not know about the Windows related change, but on Linux the one line patch in FrameLoaderClientQt::createJavaAppletWidget is sufficent to activate the Java applet support in QtWebKit granted the patch in bug# 34539 is also applied.
Hey Dawit, thanks for taking up the banner on this stuff. I'm sure Benjamin will be happy to hear that it runs on Linux.
You probably also need the method sig line above it to get the pluginSize args, etc (so 2 lines on Linux). The rest of that patch is debug statements (which aren't really needed now that it works) and locating the Java Plug-in DLL on Windows via the registry (which is needed but might be refactorable).

(In reply to comment #21)
> (In reply to comment #20)
> > I do not know about the Windows related change, but on Linux the one line patch in FrameLoaderClientQt::createJavaAppletWidget is sufficent to activate the Java applet support in QtWebKit granted the patch in bug# 34539 is also applied.
>
> Hey Dawit, thanks for taking up the banner on this stuff. I'm sure Benjamin will be happy to hear that it runs on Linux.
No problem... It is one of the items on my TODO list for the QtWebKit KDE library (kdewebkit).
> You probably also need the method sig line above it to get the pluginSize args, etc
> (so 2 lines on Linux).
Ahh yes indeed...
> The rest of that patch is debug statements (which aren't really needed now
> that it works) and locating the Java Plug-in DLL on Windows via the registry
> (which is needed but might be refactorable).
Perhaps breaking the patch for locating the Java Plugin-DLL into a separate fix as suggested in comment #1 by Kenneth would result the whole thing being accepted quickly ?

> I'm sure Benjamin will be happy to hear that it runs on Linux.
Yep. :)
> Perhaps breaking the patch for locating the Java Plugin-DLL into a separate fix as suggested in comment #1 by Kenneth would result the whole thing being accepted quickly ?
Sounds good. I can test for Mac if you need.

Created attachment 55712[details]
Activate Java applet support...
Portion of the original patch that activates java support in QtWebKit. This patch splits out the code that is used to locate the Java plugin DLL on Windows into its own separate bug report, #38911.

(In reply to comment #24)
> Created an attachment (id=55712) [details]
> Activate Java applet support...
>
> Portion of the original patch that activates java support in QtWebKit. This patch splits out the code that is used to locate the Java plugin DLL on Windows into its own separate bug report, #38911.
Garth you might want to change the dependency of this bug report to include bug #38911 as well...

(In reply to comment #23)
> > I'm sure Benjamin will be happy to hear that it runs on Linux.
>
> Yep. :)
>
>
> > Perhaps breaking the patch for locating the Java Plugin-DLL into a separate fix as suggested in comment #1 by Kenneth would result the whole thing being accepted quickly ?
>
> Sounds good. I can test for Mac if you need.
Yes, please do that...

(In reply to comment #29)
> All reviewed patches have been landed. Closing bug.
Commmiting this patch without dependencies is problematic, specially the one provided in bug# 34539. Without that patch attempting to view pages with embeded Java applet will surely cause a crash in QtWebKit now.
Additionally without the fix in bug #38911, this patch along with the one in bug# 34539 will only enable Java applet support on Linux and Unix like OSes. IOW, it will not work on Windows. Is there anyways, those patches can also be reviewed and committed soon ? Thanks.