1832033 - Change `CheckPopoverValidity` to match the spec more closely

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

https://searchfox.org/mozilla-central/rev/373d05f4eabdb90a6480d5d36d983b8bff36c9d8/dom/html/nsGenericHTMLElement.cpp#3181

https://html.spec.whatwg.org/multipage/popover.html#check-popover-validity

Comment 1

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

Attachment: Bug 1832033: change `CheckPopoverValidity` to match spec more closely. r=emilio

Comment 2

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

This requires the changes of https://github.com/web-platform-tests/wpt/pull/39781/commits/6403f546bd460256e8a8bf270f633c0799babe53#.

Comment 3

[cathiechen]

This could also be related to the failure on popover-move-documents.html, which is failed because of it generates the error "HTMLElement.hidePopover: Element has unexpected visibility state".
In the case 'Moving popovers between documents while hiding should not throw an exception.', when call p2.hidePopover();, on the 'beforetoggle' callback, p2 is moved to another frame myframe2, which calls hidePopover for p2. So when finish 'beforetoggle' callback, the status of p2 is not popover-open. And after that, calling CheckPopoverValidity, it generates an error "HTMLElement.hidePopover: Element has unexpected visibility state" because it assumes the statue should be popover-open.
So this failure could be fixed, if CheckPopoverValidity does not generate errors for data->GetPopoverVisibilityState() != aExpectedState.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/38cfebe42935
change `CheckPopoverValidity` to match spec more closely. r=emilio

Comment 5

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/38cfebe42935