fix(platform-browser): DomEventsPlugin should always be the last plugin to be called for supports(). - #50394
fix(platform-browser): DomEventsPlugin should always be the last plugin to be called for supports().#50394JeanMeche wants to merge 1 commit into
DomEventsPlugin should always be the last plugin to be called for supports().#50394Conversation
f223c82 to
60a97de
Compare
57065c6 to
fdab3b4
Compare
fdab3b4 to
9290de1
Compare
623f32e to
8edee8b
Compare
alxhub
left a comment
There was a problem hiding this comment.
Looking at the g3 failures, it looks like g3 expects to import EventManagerPlugin from the event_manager.ts file. We could update g3 when we land this change, but I don't think there's a reason to separate EventManagerPlugin into a separate file anymore - how would you feel about keeping it in event_manager.ts?
8edee8b to
beaca5d
Compare
|
It makes sense, we're down to 3 changed files. |
|
The current change ended up breaking at least one app inside Google. Currently investigating a bit why. |
45784dc to
d0d16c7
Compare
|
I reverted to using Running a TGP to make sure we're good to go. |
|
Removing the merge label, this change still needs an approval |
…ugin to be called for `supports()`. This fixes the issues when `BrowserModule` is not the first module imported. Fixes angular#37149 angular#37850
d0d16c7 to
4170765
Compare
This fixes the issues when
BrowserModuleis not the first module imported.I choose not to introduce a specific token for the
DomEventsPluginas this would likely be breaking.Fixes #37149 #37850
PR Type
What kind of change does this PR introduce?
Does this PR introduce a breaking change?