Closed Bug 3502 Opened 26 years ago Closed 25 years ago

{css2} z-index and forms

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 16272

People

(Reporter: rw263, Assigned: buster)

References

(
URL
)

Details

(Keywords: css2)

Attachments

(2 files)

Test case to demonstrate problems
(deleted), text/html
Details
This shows the same problem with iframes
(deleted), text/html
Details
When one has forms on a page: <input type=checkbox ... <input type=radio ... <input type=text ... <textarea ... <input type=submit ... <input type=reset... and then one uses a z-index to go in FRONT of those, the input areas stay in the foreground, even when with z-index they are explicitely set to the background. Please fix :(.
Assignee: troy → karnaze
If you do widgetless form elements, then this should be fixed. Otherwise, I'm not sure there's much you can do
What do you mean widgetless form elements? ZIndex is correctly displayed on MSIE with forms. (with the same html code)
Assignee: karnaze → kmcclusk
Kevin, here is a GFX test case.
Status: NEW → ASSIGNED
Target Milestone: M6
Target Milestone: M6 → M7
QA Contact: 4144 → 4078
Changing qa contact to phillip@netscape.com as this is GFX related (widget category) as indicated in 3/17 comments.
*** Bug 3183 has been marked as a duplicate of this bug. ***
here's another URL that demonstrates the same: http://webfx.eae.net/gecko/testAbsoluteIframes.html
Target Milestone: M7 → M8
Target Milestone: M8 → M9
Target Milestone: M9 → M8
Assignee: kmcclusk → buster
Status: ASSIGNED → NEW
Simple test case <HTML> <BODY> <P style="position:absolute; left:0; top:35; z-index:2; background-color:blue;"> this is in front of the form elements <P style="position:absolute; left:0px; top:0; background-color:red;"> this is behind the form elements <FORM> <INPUT type=button value="button"> <INPUT type=checkbox>checkbox <INPUT type=radio>radio <SELECT> <OPTION>item1</OPTION> <OPTION>item2</OPTION> <OPTION>item3</OPTION> </SELECT> <SELECT size=2> <OPTION>item1</OPTION> <OPTION>item2</OPTION> <OPTION>item3</OPTION> </SELECT> <INPUT type=text size=8> <TEXTAREA size=8 >contents of textarea</TEXTAREA> </FORM> </BODY> </HTML> When gfx-widgets are enabled the buttons, checkboxes, radio buttons and listbox contents go below the blue box. This is the correct behavior. The ender-widget shows and scrollbars show up on top. This is incorrect. Steve, I'm re-assigning to you for the ender bug. The scrollbar bug will be fixed when gfx-rendered scrollbars are used.
Status: NEW → ASSIGNED
Target Milestone: M8 → M10
latering to M10.
Target Milestone: M10 → M12
Summary: Z-index and forms → {css2} z-index and forms
[Adding CSS2 radar...]
QA Contact: phillip → petersen
Target Milestone: M12 → M14
moving this one out to M14, it can wait till post beta
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
I don't see the error anymore, I tried this out using the 19991102 build on win95. I'm marking this as WORKSFORME, if you can duplicate the issue, please reopen. What I was specifically looking for was the scrollbar issue showing up on top -- as described in Kevin's comments on 6/18
beth: I hope you're right, but I don't know why this would be fixed. I suspect that at least some aspects of it are not really fixed yet. If evaughan's gfx scroll bars are enabled, that would account for the improved behavior, and some cases will show up correctly. anyway, I'd ask somebody in qa to build some additional test cases involving text controls in various states and absolutely positioned elements on top and underneath them, and make sure it all looks right both when the control has focus and when it does not. for hidden text controls, focus can be forced into them using javascript. or textarea's always have a webshell, so for this problem they display as if they had focus (that is, they get a webshell.)
chrisd rechecked this and found that it isn't fixed. I am reopening the bug based on her feedback and assigning chrisd as qa contact.
Status: RESOLVED → REOPENED
QA Contact: petersen → chrisd
Resolution: WORKSFORME → ---
Created a new test case much the same as Kevin's except I used just one div with the form items. Using this example with 11/3 Apprunner, problems are still evident. The div is in front of all items except the input type=text box and the scrollbar. Will try to develop more complex tests within the next few days.
Attached file Test case to demonstrate problems (deleted) —
The div seems to be in front of everything except for the textarea and the SELECT with the size attribute. If I delete the SIZE=2 attribute from the second SELECT, the problem for that form element goes away. So, obviously it is the introduction of the scrollbar. The TEXTAREA was written incorrectly, I added the required rows and cols attributes and it works fine. The really odd thing here, is that using the example Kevin presented on 6/18 -- the scrollbar issue was not evident. Using Chirs' example, the scrollbar issue is there.
What I really wanted to show with the last attachment is that frames should also support background-color: transparent. I guess I just screw that up
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
this is a dup of 16272 *** This bug has been marked as a duplicate of 16272 ***
Status: RESOLVED → VERIFIED
Yes...marking Verified as a dup.
Keywords: css2
Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: