125162 - <editor> is always top most element

Status: NEW

(Toolkit :: UI Widgets, defect, P5)

Description

[Mike Lee]

Continue from bug 34414 <editor> is always the top most element. So no element
can be layed/float on top of <editor>. An example usage is to emulate the
netscape 4 floating component bar.

Comment 1

[Mike Lee]

Quote from bug 34414 that might outline the problem

------- Additional Comment #10 From Charles Manske 2000-07-05 18:17 -------

This bug has mutated a bit: Here's the current problem:
The XUL contains this structure:
<deck>
<editor/> // The main editor window
  <textfield/> // the HTML Source editor
</deck>
The deck frame code "hides" each child by getting its view from the press shell
and setting the size to 0,0. But recent changes in the <editor> tag (probably
by hyatt?) are such that there is no view associated directly with the 
<editor> outermost frame. Thus the deck code fails.
Temporary kludge is to wrap <editor> in a <stack>, which has a view.
I will keep this bug open so hyatt can investigate and make the proper fix,
but I'll check in the temporary <stack> fix so the feature doesn't block other
nsbeta2+ work, such as the chrome enabling/disabling (38875).

Comment 2

[Kathleen :Brade]

-->cmanske since he is doing some things with <editor> already

Comment 3

[BugBot [:suhaib / :marco]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:hsinyi, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

<editor> is a custom element implemented in toolkit. So, not an editor's bug.

Comment 5

[Magnus Melin [:mkmelin]]

See bug 1591355. editor should really be moved to comm-central

Comment 6

[Mark Striemer [:mstriemer]]

Linking to the removal bug to close this out here when <editor> moves