RESOLVED INVALID 29484
[Qt] Clicking on the frame's scrollbar trigger a click event in the page. 
https://bugs.webkit.org/show_bug.cgi?id=29484
Summary [Qt] Clicking on the frame's scrollbar trigger a click event in the page.
Tor Arne Vestbø
Reported 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.
Attachments
Add attachment proposed patch, testcase, etc.
Jocelyn Turcotte
Comment 1 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.
Benjamin Poulain
Comment 2 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.
Antonio Gomes
Comment 3 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.
Benjamin Poulain
Comment 4 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.
Antonio Gomes
Comment 5 2010-04-22 07:39:52 PDT
working on it
Antonio Gomes
Comment 6 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 :(
Antonio Gomes
Comment 7 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
Jocelyn Turcotte
Comment 8 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.
Note You need to log in before you can comment on or make changes to this bug.