HTML forms don't work in the embedded web browser. It's probably due to some missing signal handlers, or some handlers that are snagging calls and not passing them through to the right place(s).
CVS commit by staikos: Make forms work in page viewer. Doesn't fix article viewer. CCBUG: 94634 M +13 -4 pageviewer.cpp 1.21 M +1 -0 pageviewer.h 1.15 --- kdepim/akregator/src/pageviewer.cpp #1.20:1.21 @@ -79,4 +79,9 @@ PageViewer::PageViewer(QWidget *parent, connect(this, SIGNAL(canceled(const QString &)), this, SLOT(slotCancelled(const QString &))); + connect(browserExtension(), + SIGNAL(openURLRequest(const KURL&, const KParts::URLArgs&)), + this, + SLOT(formClicked(const KURL&, const KParts::URLArgs&))); + m_current = m_history.end(); m_restoring = false; @@ -390,8 +395,12 @@ void PageViewer::slotCopy( ) void PageViewer::slotSelectionChanged( ) { - if (selectedText().isEmpty()) - m_copyAction->setEnabled(false); - else - m_copyAction->setEnabled(true); + m_copyAction->setEnabled(!selectedText().isEmpty()); +} + + +void PageViewer::formClicked(const KURL& url, const KParts::URLArgs& args) +{ + browserExtension()->setURLArgs(args); + openURL(url); } --- kdepim/akregator/src/pageviewer.h #1.14:1.15 @@ -70,4 +70,5 @@ namespace Akregator void slotSelectionChanged(); void slotGlobalBookmarkArticle(); + void formClicked(const KURL& url, const KParts::URLArgs& args); signals:
Do we need forms in article viewer? It is not meant for browsing, so entering data there feels "wrong" to me. Is there any example where it'd make sense to have forms support in the article viewer? And what should happen if the user sends the message? (Writing this, I remember someone said something about polls...)
On Friday 07 January 2005 16:17, Frank Osterfeld wrote: > 22:17 ------- Do we need forms in article viewer? It is not meant for > browsing, so entering data there feels "wrong" to me. Is there any example > where it'd make sense to have forms support in the article viewer? And what > should happen if the user sends the message? (Writing this, I remember > someone said something about polls...) Correct, there are some sites providing online polls like this.
Forms work for some sites, for some sites they don't (or only partially). For an example, check http://bugs.kde.org/show_bug.cgi?id=98895
*** Bug 98895 has been marked as a duplicate of this bug. ***
CVS commit by osterfeld: make forms work again CCBUGS: 94634 M +7 -0 ChangeLog 1.88 M +5 -14 src/pageviewer.cpp 1.36 M +1 -2 src/pageviewer.h 1.24 M +2 -1 src/viewer.cpp 1.43 --- kdepim/akregator/ChangeLog #1.87:1.88 @@ -3,4 +3,11 @@ (c) 2004, 2005 the Akregator authors. +Changes after 1.0: +----------------------------- + +Bug fixes: + + - fix regression: non-working forms #94634 -fo + Changes after 1.0b9: ----------------------------- --- kdepim/akregator/src/pageviewer.cpp #1.35:1.36 @@ -96,9 +96,4 @@ PageViewer::PageViewer(QWidget *parent, connect(this, SIGNAL(canceled(const QString &)), this, SLOT(slotCancelled(const QString &))); - connect(browserExtension(), - SIGNAL(openURLRequest(const KURL&, const KParts::URLArgs&)), - this, - SLOT(formClicked(const KURL&, const KParts::URLArgs&))); - m_current = m_history.end(); m_restoring = false; @@ -224,5 +220,8 @@ void PageViewer::slotOpenURLRequest(cons Viewer::slotOpenURLRequest(url, args); else + { + browserExtension()->setURLArgs(args); openURL(url); + } } @@ -411,12 +410,4 @@ void PageViewer::slotPopupMenu(KXMLGUICl } -void PageViewer::formClicked(const KURL& url, const KParts::URLArgs& args) -{ - if (args.doPost()) { - browserExtension()->setURLArgs(args); - openURL(url); - } -} - #include "pageviewer.moc" // vim: ts=4 sw=4 et --- kdepim/akregator/src/pageviewer.h #1.23:1.24 @@ -87,5 +87,4 @@ namespace Akregator void slotGlobalBookmarkArticle(); - void formClicked(const KURL& url, const KParts::URLArgs& args); virtual void slotOpenURLRequest(const KURL& url, const KParts::URLArgs& args); --- kdepim/akregator/src/viewer.cpp #1.42:1.43 @@ -90,5 +90,5 @@ Viewer::~Viewer() bool Viewer::openURL(const KURL &url) { - new Akregator::BrowserRun(this, (QWidget*)parent(), this, url, KParts::URLArgs()); + new Akregator::BrowserRun(this, (QWidget*)parent(), this, url, browserExtension()->urlArgs()); emit started(0); return true; @@ -136,4 +136,5 @@ void Viewer::slotOpenURLRequest(const KU { m_url = url; + browserExtension()->setURLArgs(args); if (args.frameName == "_blank") // apparently this indicates that the MMB was pressed... {
> Correct, there are some sites providing online polls like this. Any examples?
Not certain about the status of this bug... looks like a lot of code has been submitted, but lord only knows what it does. In response to why you might want the ability... I use akregator to watch over several blogs that I am an active participant in. If I find a story that is interesting, read it in the article pane, and then want to respond, I know have to open a whole new browser window... even though the comment submission form is RIGHT THERE in the article pane. Seems like such a natural thing to want to do. Just my two cents as a user.
Can you give me an URL of a feed where forms show up in the article pane? I never saw one, that's the reason why I asked above for examples (which means URLs).
*** Bug 105839 has been marked as a duplicate of this bug. ***
No problem. For example: http://www.heise.de/newsticker/meldung/59619 (when opening it from the feed), then click on "Per Email versenden". It won't work. Several other examples are easy to find.
Mark: Do you use SVN HEAD or KDE 3.4?
Forms in browser tabs were fixed some time ago and will be fixed in 3.4.1. My question was wrt forms in the article preview. Which I have not seen in feeds. (There are TextInput constructs in RSS but those aren't displayed by Akregator) (In HEAD you can load the linked website directly into the preview, so we have to check if forms work in there, but 3.4.x isn't affected by this).
I use 3.4.1 and this is still an issue. Basically this bug stops me from commenting in any blog, which kind of undermines every way in which it is useful.
maybe this is because javascript is disabled
works fine here in 3.4.1 and head. maybe your konqueror settings for javascript are wrong?
I guess it they were wrong it also wouldn't work from inside Konqueror. But here it only doesn't work when I try to submit forms from KHTML embeded inside Akregator.
can you please give examples so we can reproduce it
Sorry it took so long to answer. At that time I was running 3.4.1 I think. Now I am running 3.43. I am not using akregator now since I have a poor internet connection, but this will change soon. I will look into it, after there is a KDE 3.5 for Debian
I was going to open a new bug thread, but I think it can fit here. I'm using v3.5 and buttons still don't work. You can repeat this easily: just subscribe to slashdot.org rss feed, select a story and open in in a tab and try to get the comments 'nested' instead of 'threaded'. The browser seems to do nothing when you hit the "submit" button.
Same issue in 3.5.1. I think it is nice to have. If you read blogs via akgregator sometimes you would like to write comments. If you read news, sometime you might want to change how comments are displayed. You cannot do right now. :-(
*** Bug 110815 has been marked as a duplicate of this bug. ***
I might as well use this bug... Lots of forums now have rss feeds, which is nice. When I open an article (lots of them don't contain any information, like dot.kde.org or forums.dpreview.com). It's quite annoying that when you click to open "the complete story", which is actually just the website, the page isn't rendered as well as it would be in konqueror or firefox. Simply put, although you may not want akregator to be a browser, the "complete story" pages are web-pages, so the tabs need to have full browser capability (at least as well as konqueror). I don't see why the framework of akregator cannot handle a konqueror window as a tab, so to me, this is a bug ;-) Cheers Simon
I consider this fixed in >= KDE-PIM 4.1. Reopen otherwise please, with example feeds/URLs.