Closed Bug 1848731 Opened 2 years ago Closed 2 years ago

Incorrect bounds for buttons placed after dynamically inserted content

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

RESOLVED FIXED
120 Branch
Tracking Status
firefox120 --- fixed
firefox121 --- fixed

People

(Reporter: nlapre, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ctw-23h2])

Attachments

(1 file)

STR:

  1. Open this page. Wait for the description of the product to load in. The share buttons described in step two render before the product description is inserted.
  2. Examine the bounds of the share buttons under the div with class "social-share-buttons" (Twitter, Facebook, Pinterest, and email).

Expected: The bounds of the the share buttons (and the "Add to Cart" button) are correct.
Actual: The bounds of these buttons are incorrect. The bounds appear to be as they were before the product description was loaded in.

Based on some sleuthing in the dev tools, I think that this is a Shopify template thing, so I expect this issue might occur in anything that uses Shopify.

Another interesting feature of this issue is that triggering a reflow doesn't fix the problem.

Severity: -- → S3
Accessibility Severity: --- → s3
Accessibility Severity: s3 → ---

As Morgan noted in the team meeting this morning, it'd be interesting to know if you can still reproduce this with the patch from bug 1837496 reverted.

Flags: needinfo?(nlapre)

With the patch from bug 1837496 reverted, the "Add to cart" and quantity controls have correct bounds after the content is inserted, but the "social-share-buttons" still have incorrect bounds. An interesting difference with the patch reverted: forcing a reflow by resizing the window fixes the bounds on the share buttons, which doesn't happen in Nightly.

Flags: needinfo?(nlapre)

Morgan, once again :), is this fixed by bug 1853468? Nathan noted in comment 2 that some of this was fixed with the display list patch reverted, but some of it wasn't. So, presumably, part of it at least is now fixed. However, I"m wondering whether the rest of it might be fixed too, since the fix you landed in bug 1853468 possibly handles more mutations than the pre-display list approach.

Flags: needinfo?(mreschenberg)

That page seems to 404 on me, so I tested this product page instead. Yep, seems resolved :)

Flags: needinfo?(mreschenberg)
Status: NEW → RESOLVED
Closed: 2 years ago
Depends on: 1853468
Resolution: --- → FIXED

[Removed unintentional comment.]

Target Milestone: --- → 120 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: