Version: (using KDE KDE 3.5.3) Installed from: Ubuntu Packages Downloaded and untarred gwt-1.0.21 beta (Google Web Toolkit). Opened the 'index.html' file located at the top-level of the untarred directory. In Konqueror, the menu item Info was pre-selected at the left of the screen and some information about the Google Web Toolkit was displayed. When clicking any of the other items, absolutely nothing was shown. When again selecting the 'Info' item, nothing was shown on the screen. With Firefox, each menu choice resulted in the screen displaying the corresponding AJAX goodness. If this is not a bug, how should I change settings to allow Konqueror to display gwt-AJAX? Hope this helps, Bob
I don't see any menu there at all
aha, did you mean the kitchen sink example?
OK. The problem seems to be that we're having some string objects pick up the wrong interpreter's prototype, and hence miss the instrumentation the pseudo-Java runtime put into String.prototype, making some ops fail. I think the lexical vs. dynamic interpreter split fixes it -- and the switching at least seems to work in trunk...
*** Bug 132169 has been marked as a duplicate of this bug. ***
At the rate pages are appearing that make use of the Google Web Tookit, it would be nice to have this working, specially now that the GWT is open-source.
The following page using GWT does not work well with Konqueror 4.2.2 (Gentoo): http://gwt.google.com/samples/Showcase/Showcase.html Try this in ie7, firefox, chrome or safari(???) and compare how it works. For example clicking on Widgets shows the subtree. Checkbox Radio Button Basic Button ... Clicking on Checkbox or Radio Button etc will not show anything in the content panel in Konqueror.
Works fine when identifying with Safari 3.2. As default, they seem to send us Mozilla-targeted code... Part of it uses getBoxObjectFor, which they absolutely should /NOT/ be using --- it's XUL internals that accidentally got leaked, much to horror of Mozilla developers... Also needs DOM3 compareDocumentPosition, which should be added, being standard stuff.
SVN commit 962646 by orlovich: Implement DOM3 core compareDocumentPosition; seems to be needed by GWT... This passes the cases in the not-yet-commited domts update that don't trigger bugs in XML/entity notation handling (once I fixed a problem in their generation) CCBUG:129398 M +7 -0 dom/dom_node.cpp M +36 -2 dom/dom_node.h M +15 -0 ecma/kjs_dom.cpp M +1 -1 ecma/kjs_dom.h M +100 -0 xml/dom_nodeimpl.cpp M +3 -0 xml/dom_nodeimpl.h WebSVN link: http://websvn.kde.org/?view=rev&revision=962646
SVN commit 962647 by orlovich: automatically merged revision 962646: Implement DOM3 core compareDocumentPosition; seems to be needed by GWT... This passes the cases in the not-yet-commited domts update that don't trigger bugs in XML/entity notation handling (once I fixed a problem in their generation) CCBUG:129398 M +7 -0 dom/dom_node.cpp M +36 -2 dom/dom_node.h M +15 -0 ecma/kjs_dom.cpp M +1 -1 ecma/kjs_dom.h M +100 -0 xml/dom_nodeimpl.cpp M +3 -0 xml/dom_nodeimpl.h WebSVN link: http://websvn.kde.org/?view=rev&revision=962647
Thank you for the bug report. As this report hasn't seen any changes in 10 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Dear user, KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6. Please migrate to use a QWebEngine based HTML component. We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes. For security issues, please see: https://kde.org/info/security/ Sorry that we did not fix this issue during the life-time of KHTML. Greetings Christoph Cullmann