Bug 29484 - [Qt] Clicking on the frame's scrollbar trigger a click event in the page.
Summary: [Qt] Clicking on the frame's scrollbar trigger a click event in the page.
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P3 Normal
Assignee: Nobody
URL:
Keywords: Qt
Depends on: 16809
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-18 08:45 PDT by Tor Arne Vestbø
Modified: 2014-02-03 03:15 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tor Arne Vestbø 2009-09-18 08:45:45 PDT
This bug report originated from issue QTBUG-3737
http://bugreports.qt.nokia.com/browse/QTBUG-3737

--- Description ---

If one clicks on a word on a web page in a QWebView and then double clicks the scroll bar, the sentence where the first click took origin gets selected.
Comment 1 Jocelyn Turcotte 2010-01-14 12:08:28 PST
Relevent information from the original email conversation:

[...]
What I mean is the following: 

Our java script would select a word when the user clicks on a word in
QWebview/website once on a certain word

Now we notice that even if the user clicks on the scroll bar , it is
still considered to be a click on the QWebview which means the website
it self and that's a very odd behavior
[...]

What I understood is that a web page's script will receive a click event when the user clicks on the outer frame's scrollbar. The user reports that he don't get this problem in firefox or safari. We don't have access to the user's script.
Comment 2 Benjamin Poulain 2010-03-17 05:10:28 PDT
Scrollbar are rendered by QWebFrame, it is normal that a mouse press event is sent to QWebView::event().
It might simply be a bogus script.

I close the task because we need more information on what is the problem. Please provide a use case so we can reopen this bug report.
Comment 3 Antonio Gomes 2010-03-17 08:37:49 PDT
(In reply to comment #2)
> Scrollbar are rendered by QWebFrame, it is normal that a mouse press event is
> sent to QWebView::event().
> It might simply be a bogus script.
> 
> I close the task because we need more information on what is the problem.
> Please provide a use case so we can reopen this bug report.

sorry, but I  disagree that the bug is INVALID. For many browsers I tested (including Safari and Firefox on Mac, as well as Firefox and even GtkLauncher on Linux) the scrollbars do not steal of the focus when clicked, since they are not part of the viewport, and making it to grab focus is just wrong.

It can a terrible problem when one just wants to scroll w/o losing the focus of the current <input>.

I am in favor for reopening, and I can even investigate it.
Comment 4 Benjamin Poulain 2010-03-17 08:48:49 PDT
(In reply to comment #3)
> sorry, but I  disagree that the bug is INVALID. For many browsers I tested
> (including Safari and Firefox on Mac, as well as Firefox and even GtkLauncher
> on Linux) the scrollbars do not steal of the focus when clicked, since they are
> not part of the viewport, and making it to grab focus is just wrong.
> 
> It can a terrible problem when one just wants to scroll w/o losing the focus of
> the current <input>.
> 
> I am in favor for reopening, and I can even investigate it.

I misunderstood the report.
I assigned the task to you.
Comment 5 Antonio Gomes 2010-04-22 07:39:52 PDT
working on it
Comment 6 Antonio Gomes 2010-05-03 12:23:59 PDT
> I close the task because we need more information on what is the problem.
> Please provide a use case so we can reopen this bug report.

it would be great if the original reporter of the bug could comment what is the behavior of his script in Firefox, since Firefox also sets <HTML> node as the tagetNode for clicking on scrollbars.

I am now tending to close this as INVALID or WONTFIX :(
Comment 7 Antonio Gomes 2010-05-07 12:29:20 PDT
(In reply to comment #6)
> > I close the task because we need more information on what is the problem.
> > Please provide a use case so we can reopen this bug report.
> 
> it would be great if the original reporter of the bug could comment what is the
> behavior of his script in Firefox, since Firefox also sets <HTML> node as the
> tagetNode for clicking on scrollbars.
> 
> I am now tending to close this as INVALID or WONTFIX :(

I tried to raise a discussion here [1] about what would be the desired behavior for hit testing frame scrollbar, but no reply.

I still plan to work on this bug, but without having a goal to achieve, it is not clear to me about how to fix this (or even if it needs fixing).

[1] http://permalink.gmane.org/gmane.os.opendarwin.webkit.devel/12725
Comment 8 Jocelyn Turcotte 2014-02-03 03:15:45 PST
=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.