Action(QWebPage::ToggleUnderline) does not work as expected

midnite · wrote on 7 Sept 2010, 06:26

Hello,

I'm trying to embed WebKit as a simple HTML editor via QWebView. I made it editable and it works OK, except for underline.

I use this code for "bold" setting:

@
void V6WebView::setBold(bool checked)
{
QAction* action = page()->action(QWebPage::ToggleBold);
if (action->isChecked() != checked)
action->activate(QAction::Trigger);
}

bool V6WebView::bold()
{
return page()->action(QWebPage::ToggleBold)->isChecked();
}
@

and it works OK. Same for italic.

Similarly I use this code for underline:

@
void V6WebView::setUnderline(bool checked)
{
QAction* action = page()->action(QWebPage::ToggleUnderline);
if (action->isChecked() != checked)
action->activate(QAction::Trigger);
}

bool V6WebView::underline()
{
return page()->action(QWebPage::ToggleUnderline)->isChecked();
}
@

As you can see, nothing really changes.

The problem is that when I call @V6WebView::setUnderline(true)@ on an event, then @V6WebView::setUnderline(false)@ on another event, without moving the cursor in the window, when I start typing the text is underlined (and I get a signal that makes my togglebutton set to ON). This does not happen with "bold" nor "italic". As expected, when I do the same procedure with "bold", i.e. setting it on then off, the text entered just after isn't in a bold font.

I checked the source roughly, and I saw that they do not use exactly the same sequence in EditorCommand.cpp, "bold" and "italic" use uses executeToggleStyle(...) and "underline" creates a CSSPrimitiveValue and uses it with a call to executeToggleStyleInList(...).

If this is one of the reasons it does not work as I expect, I suspect "StrikeThrough" and other similar features to have the same problem, although I didn't try because I don't need them for the moment.

Any clue?

Thanks!

midnite · wrote on 7 Sept 2010, 06:32

Oops, forgot to say: I'm using 4.7 git cloned on 2010-09-05 04:40

benjamin.poulain · wrote on 7 Sept 2010, 07:37

It souds like a bug.

I suggest you to create the smalest application possible to reproduce the bug, and open a bug report on bugzilla: "https://bugs.webkit.org/ ":https://bugs.webkit.org/ (component WebKit Qt in this case).

Once you created the bug, you can give the link here for future reference.

[edit: fixed hyperlink / $chetankjain]

midnite · wrote on 9 Sept 2010, 22:40

I've written a test case, simplified, and the behavior is not exactly the same while still buggy. Please see "https://bugs.webkit.org/show_bug.cgi?id=45499":https://bugs.webkit.org/show_bug.cgi?id=45499

midnite · wrote on 11 Sept 2010, 16:27

Well.. I tried the same source code (not the one in my bug report but the one in the first post of this topic) against Qt 524379030503600bbca1a8e2b5889b91b0798203, and now it works ok... Go figure... ;-)

Anyway, the bug reported "here":https://bugs.webkit.org/show_bug.cgi?id=45499 is still valid and is not quite the same.

For archive.

Edited 2010-09-11 17:24 UTC:

Sorry, my bad, my fault, behavior did not change :-(

Please ignore this post.

midnite · wrote on 11 Sept 2010, 17:38

I should take more care in posting bugs...

The source code of this "bug":https://bugs.webkit.org/show_bug.cgi?id=45499 also shows the problem when you follow the same procedure.

Sorry for bad reporting.