Closed Bug 1731504 Opened 3 years ago Closed 1 year ago

bubbling & capturing event are in wrong order

Categories

(Core :: DOM: Events, defect, P3)

Product:
Core
Component:
DOM: Events
Version:
Firefox 92
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
116 Branch
Tracking Flags:
Tracking Status
firefox116 --- fixed

People

(Reporter: frederic.linot, Assigned: vhilla)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: perf-alert)

Attachments

(2 files, 1 obsolete file)

Bug 1731504 - Explicitly call capturing listeners before bubbling listeners on target. r=smaug
48 bytes, text/x-phabricator-request
Details | Review
Bug 1731504 - Activate dom.events.phases.correctOrderOnTarget in Nightly. r=smaug
48 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

<html>
<head><title>Titre de la page</title></head>
<body>
<div id="monDiv">
<a href='#' id="monLien">Ordre des phases de capture & bouillonnement.</a>
<p>Un paragraphe</p>
</div>
<script>
monDiv.addEventListener('click', function(e) {
console.log(e.currentTarget) ;
alert("DIV (bubbling).");
}, false);

monLien.addEventListener('click', function(e) {
    console.log(e.currentTarget) ;
    alert("Link (bubbling).");
}, false);

 monDiv.addEventListener('click', function(e) {
    console.log(e.currentTarget) ;
    alert("DIV (capturing).");
}, true);

monLien.addEventListener('click', function(e) {
    console.log(e.currentTarget) ;
    alert("Link (capturing).");
}, true);

</script>
</body>
</html>

Actual results:

DIV (capturing).
Link (bubbling)
Link (capturing).
DIV (bubbling)

Expected results:

DIV (capturing)
Link (capturing)
Link (bubbling)
DIV (bubbling)

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
Component: DOM: Core & HTML → DOM: Events

Changing severity to S1 because impact more than 25% users.

Severity: -- → S1
tracking-firefox93: --- → ?
tracking-firefox94: --- → ?
Priority: -- → P1

Please don't change tracking and severity/priority flags, this will be set by the triaging team, thanks.

Severity: S1 → --
tracking-firefox93: ? → ---
tracking-firefox94: ? → ---
Priority: P1 → --

smaug, should this be more severe?

Confirmed: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/9651

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(bugs)
Priority: -- → P3

I think this should be more severe because all codes with for example stopPropagation in capturing phase whill not work anymore...

The specs on this have changed couple of times, so what Gecko has is some variant of some older version of a spec.
(at some point capturing listeners weren't supposed to fire at all at target phase)

A patch coming, let's see how many tests will be broken.

Assignee: nobody → bugs
Flags: needinfo?(bugs)
Pushed by opettay@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6a408466ecb6 WIP: Bug 1731504, explicitly call capturing listeners before bubbling listeners at target r=masayuki

https://hg.mozilla.org/mozilla-central/rev/6a408466ecb6

Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox95: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
Regressions: 1739045

== Change summary for alert #32168 (as of Thu, 28 Oct 2021 19:56:23 GMT) ==

Improvements:

Ratio Test Platform Options Absolute values (old vs new)
92% ebay LastVisualChange windows10-64-shippable-qr warm webrender 4,376.17 -> 342.75
92% ebay LastVisualChange linux1804-64-shippable-qr warm webrender 4,436.67 -> 360.00
91% ebay LastVisualChange macosx1015-64-shippable-qr warm webrender 4,483.33 -> 423.33
89% ebay SpeedIndex windows10-64-shippable-qr warm webrender 2,171.17 -> 248.08
88% ebay LastVisualChange macosx1014-64-shippable-qr warm webrender 4,613.33 -> 540.00
... ... ... ... ...
34% ebay ContentfulSpeedIndex macosx1014-64-shippable-qr cold webrender 1,545.67 -> 1,023.75

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=32168

Backed out for causing Bug 1739045

Status: RESOLVED → REOPENED
status-firefox95: fixed → ---
Flags: needinfo?(bugs)
Resolution: FIXED → ---
Target Milestone: 95 Branch → ---

So ebay is more important than standards for Firefox...

Are you shure #1739045 is realy a bug ? Have you checked that eBay had not created a specific rule for Firefox in order to work around your bug which has existed for so long ?

Backing out a patch doesn't mean the change will never happen. If a change causes major issues, it should be backed out asap and debugging the issue can happen then using local builds.

Flags: needinfo?(bugs)

(In reply to Cristian Tuns from comment #12)

Backed out for causing Bug 1739045

== Change summary for alert #32307 (as of Mon, 08 Nov 2021 12:15:55 GMT) ==

Regressions:

Ratio Test Platform Options Absolute values (old vs new)
1195% ebay LastVisualChange windows10-64-shippable-qr warm webrender 337.75 -> 4,372.33
1132% ebay LastVisualChange linux1804-64-shippable-qr warm webrender 360.00 -> 4,436.67
1132% ebay LastVisualChange linux1804-64-shippable-qr warm webrender 360.00 -> 4,436.67
1132% ebay LastVisualChange linux1804-64-shippable-qr warm webrender 360.00 -> 4,436.67
942% ebay LastVisualChange macosx1015-64-shippable-qr warm webrender 430.00 -> 4,480.00
781% ebay SpeedIndex windows10-64-shippable-qr warm webrender 245.92 -> 2,167.67
756% ebay LastVisualChange macosx1014-64-shippable-qr warm webrender 540.00 -> 4,620.00
734% ebay SpeedIndex linux1804-64-shippable-qr warm webrender 258.33 -> 2,154.58
656% ebay PerceptualSpeedIndex windows10-64-shippable-qr warm webrender 240.17 -> 1,815.25
619% ebay PerceptualSpeedIndex linux1804-64-shippable-qr warm webrender 253.00 -> 1,818.08
... ... ... ... ...
139% ebay ContentfulSpeedIndex macosx1014-64-shippable-qr warm webrender 393.25 -> 939.67
88% ebay ContentfulSpeedIndex windows10-64-shippable-qr cold webrender 599.50 -> 1,125.75
73% ebay ContentfulSpeedIndex linux1804-64-shippable-qr cold webrender 681.17 -> 1,178.75
60% ebay ContentfulSpeedIndex macosx1015-64-shippable-qr cold webrender 778.75 -> 1,244.08
50% ebay ContentfulSpeedIndex macosx1014-64-shippable-qr cold webrender 1,043.00 -> 1,563.92

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=32307

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:smaug, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(masayuki)
Flags: needinfo?(bugs)
Flags: needinfo?(masayuki)

FWIW, I just tried out an old build with the patches here. It's working well on ebay. Something may have been fixed on ebay? Anyway, I think it's worth we try to re-land the patche to improve this interoperability issue.

Talked with Olli, we appreciate Vincent's help here :)

Assignee: smaug → vhilla
Flags: needinfo?(smaug)

There is work ongoing on getting this fixed, see the phab revision.

Pushed by vhilla@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b4fc853b69f6 Explicitly call capturing listeners before bubbling listeners on target. r=smaug

https://hg.mozilla.org/mozilla-central/rev/b4fc853b69f6

Status: REOPENED → RESOLVED
Closed: 3 years ago → 1 years ago
status-firefox116: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 116 Branch
Status: RESOLVED → REOPENED
status-firefox116: fixed → ---
Resolution: FIXED → ---
Target Milestone: 116 Branch → ---

The perf regression persists also with the updated eBay version: comparison

Pushed by vhilla@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e3ae94bce193 Activate dom.events.phases.correctOrderOnTarget in Nightly. r=smaug

https://hg.mozilla.org/mozilla-central/rev/e3ae94bce193

Status: REOPENED → RESOLVED
Closed: 1 years ago → 1 year ago
status-firefox116: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 116 Branch

The flag is only enabled on Nightly, why close the issue then? As it stands, there’s no guarantee it will land in 116 stable.

Right, we want to get some testing in Nightly before fully activating the pref. Also, wpt metadata of this kind should be removed.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Usually we'd close the bug when the code has landed and then open a new bug to enable it everywhere.

See Also: → 1840620
Status: REOPENED → RESOLVED
Closed: 1 year ago → 1 year ago
status-firefox116: affected → fixed
Resolution: --- → FIXED
QA Whiteboard: [qa-116b-p2]
Attachment #9246750 - Attachment is obsolete: true
Duplicate of this bug: 1837319
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: