Sign in form is not displayed on tv.apple.com
Categories
(Core :: Web Painting, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox119 | --- | unaffected |
firefox120 | + | fixed |
firefox121 | --- | fixed |
People
(Reporter: ksenia, Assigned: emilio)
References
(Blocks 1 open bug, Regression, )
Details
(Keywords: regression)
Attachments
(2 files, 1 obsolete file)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
10.35 KB,
text/plain
|
diannaS
:
approval-mozilla-beta+
|
Details |
We've received a report in https://github.com/webcompat/web-bugs/issues/129369 where a user is unable to sign in on tv.apple.com.
To reproduce,
- Visit https://tv.apple.com/ in Nightly 121.0a1 (2023-11-04) and click on the "Sign In" button in the top-right
Expected:
"Sign In or Sign Up" form is displayed
Actual:
The form is not displayed
From mozregression:
Last good revision: 017ed2bc0c5d9eacf5f2d764f29f65c8b6edf868
First bad revision: cd7366c6b55dcaff0f6bedd5fe2cc8ea2783be30
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=017ed2bc0c5d9eacf5f2d764f29f65c8b6edf868&tochange=cd7366c6b55dcaff0f6bedd5fe2cc8ea2783be30
Reporter | ||
Comment 1•6 months ago
|
||
Hi Emilio, wonder if you could take a look at this, please?
Assignee | ||
Comment 2•6 months ago
|
||
So this is kind of expected given how they deal with the dialog. It seems they're trying to make a fixed transparent dialog, and they are relying on a fixed-pos inside the dialog to escape. In fact on "working builds" even in chrome or what not, you can see that the dialog is a little white square behind the backdrop.
They could use something like this instead:
#ck-modal {
position: fixed;
inset: 0;
border: none;
width: auto;
height: auto;
background: transparent;
max-width: none;
max-height: none;
}
And it'd work in all browsers. Is there any chance we could contact them? Otherwise we could add an intervention or something, perhaps, but it seems unfortunate. I'll try to find some contact too.
Updated•6 months ago
|
Assignee | ||
Comment 4•6 months ago
|
||
[Tracking Requested - why for this release]: Pretty severe bug on apple site.
Assignee | ||
Updated•6 months ago
|
Reporter | ||
Comment 5•6 months ago
|
||
Yeah, I'll try to find a contact as well. In the meantime I can add an intervention and would need to do an uplift to beta
Comment 6•6 months ago
|
||
This is reported and tracked at Apple by rdar://118018661
Assignee | ||
Comment 7•6 months ago
|
||
The top layer fixed list CB and the regular fixed list CB are always the
same (the viewport frame).
We're currently sharing frame lists for these, so also share the same
AbsoluteFrameList. This makes sure that placeholders for the fixed list
are properly ordered.
Revert bug 1799036 (for now at least), since this also fixes it in a
better, less breaking way.
While at it, also insert the top layer fixed pos list after the
non-top-layer one. This is needed so that a non-top-layer abspos element
and a top layer abspos element are laid out in the right order. We don't
need to share a list for those tho, because all top-layer abspos items
are also abspos containers themselves, so we can't get a non-top-layer
sibling a top layer abspos. This fixes a couple non-fatal asserts.
Updated•6 months ago
|
Assignee | ||
Comment 8•6 months ago
|
||
Can we hold off on the intervention for now? I think comment 7 could be uplifted, or we could back out the regressing bug for now.
Apple should still consider applying something like the fix in comment 2 tho, if only to remove the annoying tiny square that the current <dialog>
imposes.
Reporter | ||
Comment 9•6 months ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)
Can we hold off on the intervention for now? I think comment 7 could be uplifted, or we could back out the regressing bug for now.
Apple should still consider applying something like the fix in comment 2 tho, if only to remove the annoying tiny square that the current
<dialog>
imposes.
Yeah, sounds good, I won't ship the intervention then. Thanks for looking into this:)
Assignee | ||
Comment 10•6 months ago
|
||
The top layer fixed list CB and the regular fixed list CB are always the
same (the viewport frame). We're currently using two different
AbsoluteFrameList for these, but that's wrong. Make sure to use the same
AbsoluteFrameList. This makes sure that placeholders for the fixed list
are properly ordered.
Revert bug 1799036 (for now at least), since this also fixes that issue
in a better, less breaking way.
While at it, also insert the top layer abspos list after the
non-top-layer one. This is needed so that a non-top-layer abspos element
and a top layer abspos element are laid out in the right order.
We don't need to share a list for those tho, because all top-layer
abspos items are also abspos containers themselves, so we can't get a
non-top-layer sibling a top layer abspos. This fixes a couple non-fatal
asserts.
Updated•6 months ago
|
Updated•6 months ago
|
Comment 11•6 months ago
|
||
Are we still planning landing this before b9? (tomorrow is the last day to uplift before RC week)
does this just need review?
Comment 12•6 months ago
|
||
Yeah, sorry for not getting to this sooner. I'll review before going to bed tonight.
(uplift-wise: Emilio's probably in the best position to weigh in on whether this patch vs. a clean backout (per comment 8) feels safer to uplift.)
Assignee | ||
Comment 13•6 months ago
|
||
Let's back out the regressing bug from beta. Dianna can you do that?
Comment 14•6 months ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/820ffb716b9d Simplify top layer fixed list set-up and back out bug 1799036. r=dholbert
Assignee | ||
Updated•6 months ago
|
Comment 15•6 months ago
|
||
bugherder |
Assignee | ||
Comment 17•6 months ago
|
||
Comment 18•6 months ago
•
|
||
Comment on attachment 9362879 [details]
Rebased backout of regressing bug.
Approved for backout of bug 1799036 in 120.0b9
Comment 19•6 months ago
|
||
fixed by backout of bug bug 1799036 in 120 #c17
fixed by backout+patch in 121 in this ticket #c15
Comment 20•5 months ago
|
||
There are some cases of popover still reproducing this assertion:
- css/css-contain/content-visibility/content-visibility-with-top-layer-in-auto-subtree-removal.html
- https://phabricator.services.mozilla.com/D175930
Description
•