Closed
Bug 772197
Opened 12 years ago
Closed 7 years ago
ENH: panel anchoring
Categories
(Add-on SDK Graveyard :: General, defect, P3)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: glind, Unassigned)
References
Details
Anchoring can go on any element (great!), but it is tempting to anchor on a location, rather than get it indirectly using Bounding Boxes.
Sometimes I want to anchor on a point, and not on an element.
Impl: add a 'where' argument to .show(), that takes an object with x,y properties.
See a diff for usage:
https://gist.github.com/gregglind/iconcontextmenus/commit/8667366540435dc8ca19b57d6c51d6a7ce1c1818#lib/panel.js
Overlaps with https://bugzilla.mozilla.org/show_bug.cgi?id=732294
What would be the use case for this?
Would being able to create a sidebar (or a bottom-bar) cover this?
Whiteboard: [triage:followup]
Reporter | ||
Comment 2•12 years ago
|
||
Not for the case I did at https://gist.github.com/gregglind/iconcontextmenus, where I used it to make new 'right click' menus, and I wanted them to anchor at the site of the right click.
Having a defined sub-bar or side-bar is an awesome *addition* though. In the general case, panel is a simplified constructor for 'html in a new XUL window'.
Maybe Panel should subclass (XUL_Iframe_Widget) or similar?
(Basically, me having 'loose panels', allowed me to do a really interested experiment that would have been *really hard* to do even through straight XUL. I want to see that *opened up*, not more restricted).
P3, but this probably won't be taken care of anytime soon.
Priority: -- → P3
Whiteboard: [triage:followup]
Comment 4•7 years ago
|
||
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Comment 5•7 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•