Closed
Bug 1042082
Opened 10 years ago
Closed 6 years ago
Chrome event bubbles are displayed when they shouldn't be
Categories
(DevTools :: Inspector, defect, P2)
Tracking
(firefox67 fixed)
RESOLVED
FIXED
Firefox 67
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: rowbot, Assigned: miker)
References
Details
Attachments
(3 files)
Steps to reproduce:
1) Open attached test case.
2) Open Inspector and click on the event button next to the video element in the html pane.
Actual Results:
The chrome event listeners for the native video controls are displayed.
Expected Results:
The chrome event listeners should not be displayed. Only event listeners added by the web page should be displayed.
Reporter | ||
Comment 1•10 years ago
|
||
Object, embed, and applet elements also seem to display chrome events when they shouldn't.
The long list of media events shows that the tooltip window can quickly overflow, with no way to scroll, when there are a lot of events attached to a single element. Seems like that should be a separate bug.
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → mratcliffe
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•10 years ago
|
||
So the way we think it should work:
if devtools.chrome.enabled === true {
- Show chrome event bubbles
- Clicking debug opens the script in the debugger with breakpoints disabled (I doubt this is even possible)
} else {
- Do not show events for chrome:// urls
}
Assignee | ||
Comment 3•10 years ago
|
||
(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #2)
> So the way we think it should work:
>
> if devtools.chrome.enabled === true {
> - Show chrome event bubbles
> - Clicking debug opens the script in the debugger with breakpoints
> disabled (I doubt this is even possible)
> } else {
> - Do not show events for chrome:// urls
> }
The fact that the file can be opened in the debugger but not debugged would be confusing. We should use this approach instead:
if isRemote() {
- Show chrome event bubbles
- Clicking debug opens the script in the debugger
} else {
- Do not show events for chrome:// urls
}
Reporter | ||
Comment 4•10 years ago
|
||
I'm sorry, were you waiting for a reply from me? After thinking about this for a while, it seems to me that the only people who might find this useful are the firefox developers themselves. So I guess the question is, who would make use of seeing these events, other than firefox developers?
The events that show on object, embed, and applet tags are the overflow and underflow, and those events seem to be related to click-to-play. I'm not a plugin developer by any means, but as far as I can tell, developing a plugin does not require knowledge of these events. As for the video/audio elements, if someone wanted to create their own controls, they would hide the native controls, which removes the chrome events, and attach their own events.
Another option would be to create an entirely new about:config option that is not linked to remote or chrome debugging, which firefox developers could then toggle for themselves.
Comment 5•10 years ago
|
||
(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #3)
> The fact that the file can be opened in the debugger but not debugged would
> be confusing. We should use this approach instead:
> if isRemote() {
> - Show chrome event bubbles
> - Clicking debug opens the script in the debugger
> } else {
> - Do not show events for chrome:// urls
> }
I think the condition check should be:
if (target.chrome)
or to be a bit future-proof (since the inspector is not currently enabled for add-on debugging), maybe even:
if (target.chrome || target.isAddon)
chrome:// scripts would only be loaded by the debugger when debugging chrome content.
On a separate note, we really should start using the same code for getting the events in both tools. Right now they both show handlers from chrome code, but the debugger shows a lot less in this test page, for better or for worse.
Assignee | ||
Updated•7 years ago
|
Has Regression Range: --- → irrelevant
Has STR: --- → yes
Hardware: x86_64 → All
Assignee | ||
Comment 7•7 years ago
•
|
||
pbro showed that he also has issues when this extension is installed:
https://addons.mozilla.org/en-US/firefox/addon/devtools-highlighter/
He opens `devtools/client/inspector/test/doc_inspector_add_node.html` and he has `pagehide` and `pageshow` listeners from his extension.
Updated•6 years ago
|
Product: Firefox → DevTools
Assignee | ||
Updated•6 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P2
Summary: [visual events] chrome events are displayed when they shouldn't be → Chrome event bubbles are displayed when they shouldn't be
Comment 8•6 years ago
|
||
I agree with comment 2 that if it's easy, it would be nice to show the chrome/webext events when devtools.chrome.enabled (or another pref).
Assignee | ||
Comment 9•6 years ago
|
||
Assignee | ||
Comment 10•6 years ago
|
||
Assignee | ||
Comment 11•6 years ago
|
||
Comment 12•6 years ago
|
||
Pushed by mratcliffe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a3bbf59239a6
Chrome event bubbles are displayed when they shouldn't be r=ochameau
Comment 13•6 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox67:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
Comment 14•6 years ago
|
||
bugherder |
You need to log in
before you can comment on or make changes to this bug.
Description
•