Closed Bug 16272 Opened 25 years ago Closed 24 years ago

Text Input fields always above all layers

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: Klaus.Malorny, Assigned: kinmoz)

References

Details

<input type=text> widgets (and probably others) are always on top of all
layers, ignoring any z order. Compare to IE5 for correct rendering.

I think this problem is caused by the fact that the widgets are implemented as
own system windows, so that the base window is not able to include these in the
normal drawing process - it seems to be more a design issue than a bug.
I assumed that this would happen only when using native widgets, but in the
meantime I fear that this behaviour will also appear with the GFX widgets.

Being not able to position a layer above the whole content is IMHO a major
drawback, which makes the CSS feature nearly useless in some cases.

Here is a small example to demonstrate the effect:

<html><head>
<style>
.mylayer
{ position: absolute;
  background: #CCCCCC;
  top: 20px;
  left: 20px;
  width: 100px;
  height: 200px;
}
</style></head>
<body>
this is a simple text<br>
this is a simple text<br>
this is a simple text<br>
this is a simple text<br>
<form><input type=text></form>
<div class=mylayer>This is the layer</div>
</body></html>
Assignee: troy → buster
Status: NEW → ASSIGNED
Target Milestone: M12
The submitter has diagnosed the problem perfectly.  This will always be the case
if webshells (soon to be docShells) require a native widget.  If the webshell
redesign goes well and can take advantage of evaughan's new windowless
scrollers, this should just fall right out.
Target Milestone: M12 → M13
depends on new docshell work landing.  set to M13.
Blocks: 18445
Target Milestone: M13 → M15
It's unclear when lightweight docshells will be available.  Pushing this back to
M15, since it's dependent on lightweight docshells.
*** Bug 3502 has been marked as a duplicate of this bug. ***
** See bug 3502 for additional test cases! **
QA Contact: petersen → chrisd
*** Bug 32401 has been marked as a duplicate of this bug. ***
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
Target Milestone: M16 → M18
Reassigining to beppe (editor).
Assignee: buster → beppe
Status: ASSIGNED → NEW
assigning to Kin for review
Assignee: beppe → kin
Accepting bug. This may not be a problem once we start using Ender-Lite which
will share the same native window as the document that contains it. Ender lite
is currently scheduled to be turned on in M16 if we don't run into any snags.
Status: NEW → ASSIGNED
Nom. nsbeta3, recc. nsbeta3+. (Expect this to be fixed by then anyway, but want 
to be sure.) Having this behavior work correctly is critically important for 
enabling rich web applications with rich user interfaces that hide, show, and 
stack HTML form controls using DOM, CSS, and JS.
Keywords: nsbeta3
checked this on yesterday's build and this is fixed. Ender lite did indeed fix 
this little issue
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Using 7/20 build, layer is on top of input box. Verifying bug fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.