[Webkit-unassigned] [Bug 165073] [GTK] Regression: "notify::title" signal unreliably triggered multiple times

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Nov 30 06:34:19 PST 2016


https://bugs.webkit.org/show_bug.cgi?id=165073

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cdumez at apple.com,
                   |                            |cgarcia at igalia.com,
                   |                            |darin at apple.com

--- Comment #3 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #2)
> Returning null makes sense when the title is changed but remains the same as
> the last one (e.g. "One" → "One"). Currently, an application would still
> receive the signal and take action (in this case, print to the terminal)
> whereas the behaviour in 2.12 did not trigger (a workaround was getting the
> JavaScript to set the title to null after xx milliseconds).
> 
> However, while a null can be ignored, the problem lies that clicking any
> sequential links does this: "One clicked" → null → "One clicked", causing
> the application to trigger its action twice.
> 
> An ideal solution would be to only notify a title change once, so it's
> compatible with 2.12 behaviour: "One clicked" → null ... "Two clicked" →
> null ... etc

So, if I understand the thing correctly, with your test case in 2.12 you clicked on one clicked and then you got "One clicked" only, then you clicked on two clicked and you got, null and then "Two Clicked", right? So, the different with 2.14 is the first "Two Clicked" in this case.

If that's the case, I think it has nothing to do with the WebView title property actually, but with the document title handling. My guess is that for whatever reason in 2.12 the title change didn't really happen because of the new load, but in 2.14 the title change is processed before the new load starts. I guess something changed in WebCore regarding the onclick event. Your test cases does:

<a href="#" onclick="cmd('One clicked.')">One</a><br>
<a href="#" onclick="cmd('Two clicked.')">Two</a><br>
<a href="#" onclick="cmd('Three clicked.')">Three</a>

And cmd just changes document.title. So what happens is that onclick events are handled and title changes, from One clicked to Two clicked for example. Then the new load starts and the title is reset on committed, so you get the null. Then the load happens and title is set again. I see your point, though, that if title is going to be the same, we change it for nothing, but on committed the PageLoadObserver doesn't know the title yet. This is not GTK+ specific issue in any case. Maybe Darin or Chris know what changed in WebCore.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161130/9fc35e9d/attachment.html>


More information about the webkit-unassigned mailing list