Open Bug 1413099 Opened 7 years ago Updated 2 years ago

Module to synchronize popup/panel UI positions with elements in content (for autocomplete, validation, <select>, etc.)

Categories

(Firefox :: General, enhancement, P2)

Product:
Firefox
Component:
General
Type:
enhancement

Tracking

()

People

(Reporter: MattN, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [tech-debt])

User Story

Some of the DOM events currently used or available:
* resize
* MozScrolledAreaChanged
* mozvisualscroll
* scroll
* FullZoomChange
* TextZoomChange
* ZoomChangeUsingMouseWheel
* MozAfterPaint
* pagehide

Some things to handle:
* zoom changes
* page is unloaded/hidden 
* ownerDocument scrolling
* viewport resizes
* should handle a parent frame scrolling while the chrome UI is attached to an inner frame.
* handle a position change due to a stylesheet load (e.g. bug 1329333).
* stay constrained to the <browser> viewport area
* Ideally handle overflow: auto, not just the whole document scrolling
* entering DOM fullscreen mode
We have at least three different pieces of chrome UI that visually attach themselves to web content UI, specifically form elements: * form validation arrow panels * autocomplete (for form history, autofill, and login manager) * The <select> dropdown options Other related consumers: * FinderHighlighter.jsm for highlighting find-in-page matches is also similar. * Tooltips e.g. from @title in content (bug 1236458) Each of them have their own logic to detect position changes in the web content and respond to them so each implementation has its own bugs and limitations but they all want to know the same kinds of information. I think it would improve the quality of the product if there was a common module that all of these UI components used to know when the form element position changed. Ideally that module would also help reposition the popup/panel to the new location when the change wasn't caused by the user (e.g. the webpage layout changed due to a CSS stylesheet loading), as that would be better than always closing the popup (like the html validation one does). We could consult with someone on the layout team to see if a new API could be provided to synchronize positions after layout changes if the existing half-dozen DOM events aren't enough or aren't performant enough.
I'd like to add date/time picker to the consumer list. And yes, it'd be great if we had this! :)

Hi Razvan,

All the various popups that appear over content have to address a similar problem as bug 1598307 and I wondered if there would be a way to share the approach (either code or just hooks into layout) used to address this longstanding bug (since e10s). Anything info you could share would be great, thanks.

You might also be interested in the list in the User Story to make sure you handle all those cases.

Flags: needinfo?(razvan.caliman)
Priority: P3 → P2
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1598307

Hi Matthew,

Historically, highlighters in DevTools have relied on a requestAnimationFrame loop where getBoxQuads() is called on the inspected node. When the box quads, scroll or zoom change, the UI of the highlighter is updated accordingly. Checks are done to get "adjusted quads" in relation to the top-level document. This has worked well over time and the intent is to keep the behavior (mostly keep the necessary rewrite for highlighters for Fission as small as possible).

With Fission, we intend to keep this approach in DevTools. But we need to get additional platform support in order to get box quads relevant to the top-level document which may be in a different process if inspecting a node in a nested frame from a different process. See bug 1593756.

If there is a desire to implement a mechanism to track node position changes directly on the platform, perhaps like an observer, we'd be interested to learn about it and share some use cases.

Highlighters in DevTools have a few more needs than just tracking node position. For example getting updated node attributes, like id, class names, measuring color contrast between text content and background, or getting some information from the node's ancestors (ex: from grid/flex container). These still require direct access to the node and monitoring it directly.

Work for this will happen in bug 1598307. We're still learning about the complexities and pitfalls of rendering in the parent process while observing nodes in content process. Impact on synchronizing with smooth scroll stands out. We already have a discontinued prototype in bug 1572651 which we be removed soon because it was the wrong approach to communicate cross-process.

(please ni? me on my mozilla email address)

Flags: needinfo?(razvan.caliman)
User Story: (updated)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.