| Summary: | [Qt] Clicking on the frame's scrollbar trigger a click event in the page. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Tor Arne Vestbø <vestbo> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | benjamin, jturcotte, tonikitoo |
| Priority: | P3 | Keywords: | Qt |
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | 16809 | ||
| Bug Blocks: | |||
|
Description
Tor Arne Vestbø
2009-09-18 08:45:45 PDT
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. 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. (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. (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. working on it > 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 :(
(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 === 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. |