Closed
Bug 49740
Opened 25 years ago
Closed 25 years ago
[FIX]input controls (type=button) have incorrect style context parentage
Categories
(Core :: Layout: Form Controls, defect, P3)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: attinasi, Assigned: rods)
Details
(Whiteboard: [nsbeta3+];requesting engineer feedback-ckritzer;)
Attachments
(3 files)
|
(deleted),
patch
|
Details | Diff | Splinter Review | |
|
(deleted),
patch
|
Details | Diff | Splinter Review | |
|
(deleted),
text/html
|
Details |
The style system complains about <input type=button> having incorrect style
context parent (with NSPR_LOG_MODULES=styleverifytree:1):
Here is the output from loading a page with only
<body><input type=button></body>
frame: Text(-1) (02FBAE00) style: 03C3ECA0 :-moz-text {}
Wrong parent style context: style: 03C389A0 {
http://www.w3.org/1999/xhtml|input weight: 1 { user-focus: normal }
http://www.w3.org/1999/xhtml|input weight: 1 { font-family: "-moz-fixed" color
: "black" background-color: "white" cursor: 14[0xe]enum vertical-align: 17[0x11]
enum border-top-width: 2px border-right-width: 2px border-bottom-width: 2px bord
er-left-width: 2px border-color: (0xcc 0xcc 0xcc 0xff)rbga (0xcc 0xcc 0xcc 0xff)
rbga (0xcc 0xcc 0xcc 0xff)rbga (0xcc 0xcc 0xcc 0xff)rbga border-style: 8[0x8]enu
m 8[0x8]enum 8[0x8]enum 8[0x8]enum box-sizing: 2[0x2]enum behavior: url("chrome:
//global/content/platformHTMLBindings.xml#inputFields") }
http://www.w3.org/1999/xhtml|*:first-node > http://www.w3.org/1999/xhtml|body
weight: 257 { margin-top: 0pt }
http://www.w3.org/1999/xhtml|input[|type=button] weight: 257 { font-family: "s
ans-serif" font-size: 2[0x2]enum color: "black" background-color: (0xce 0xcf 0xc
e 0xff)rbga cursor: 3[0x3]enum white-space: 1[0x1]enum padding-top: 1px padding-
right: 1px padding-bottom: 1px padding-left: 1px border-top-width: 2px border-ri
ght-width: 2px border-bottom-width: 2px border-left-width: 2px border-color: (0x
9c 0x9a 0x9c 0xff)rbga (0x9c 0x9a 0x9c 0xff)rbga (0x9c 0x9a 0x9c 0xff)rbga (0x9c
0x9a 0x9c 0xff)rbga border-style: 9[0x9]enum 9[0x9]enum 9[0x9]enum 9[0x9]enum b
ox-sizing: 2[0x2]enum behavior: none }
type = 5[0x5]enum
}
should be using: style: 03C3D970 :button-content {
*|:button-content weight: 0 { text-align: 3[0x3]enum display: 1[0x1]enum }
}
The frame creation code needs to be checked and modified to pass the make sure
that the style contexts match the frames in terms of parentage.
(note: this happens for <input type=file> also, but that is probably because it
uses a button.)
|
Reporter | |
Comment 1•25 years ago
|
||
|
|
Reporter | |
Comment 2•25 years ago
|
||
Rod, I added a patch to nsFrameManager that will cause it to ignore tables when
it does the verification of the style tree. I gets rid of 75% of the noise.
There is another patch that takes care of the FrameInner which is the remaining
25% attached to bug 49739.
|
Assignee | |
Comment 3•25 years ago
|
||
This will take a little bit of time, evaughan wrote the code.
Status: NEW → ASSIGNED
|
|
Assignee | |
Comment 4•25 years ago
|
||
|
|
Assignee | |
Comment 5•25 years ago
|
||
I have included a patch for fixing the GfxButton.
The real issue is that there is a built in assumption in the
nsCSSFrameConstructor that all child will be added directly to the parent frame.
This is wrong. There are several cases where the children are added to an
intermediate frame and the problem is the children being added are having their
new style context's resoved against the "assumed" parent frame instead of the
"real" that they will soon be a child of. Marc and I discussed several was to
fix this, but there is going to have to be a new call to either get the real
parent frame or the "real" parent style context.
|
|
Reporter | |
Comment 6•25 years ago
|
||
I'm nominating this because we really need to get all of our style contexts
created correctly: 1) incorrect style context parentage causes unnecesary
performance problems in ReResolveStyle and 2) incorrect style context parentage
can cause incorrect styling if the impacts are evaluated incorrectly due to
comparing against the wrong context.
The current patch will solve at least the <input> case, even if the <button>
case needs more work...
Keywords: nsbeta3
|
|
Assignee | |
Updated•25 years ago
|
Target Milestone: --- → M18
|
|
Assignee | |
Updated•25 years ago
|
Summary: input controls (type=button) have incorrect style context parentage → [FIX]input controls (type=button) have incorrect style context parentage
|
|
Assignee | |
Comment 8•25 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
||
Comment 9•24 years ago
|
||
|
|
||
Comment 10•24 years ago
|
||
[Rod|Marc] what would be the best way to test this?
Whiteboard: [nsbeta3+] → [nsbeta3+];requesting engineer feedback-ckritzer;
|
|
Reporter | |
Comment 11•24 years ago
|
||
Using a debug build, set and environment variable
NSPR_LOG_MODULES=styleverifytree:1
and run Mozilla or Viewer. Load a page with an HTML button and you will see that
the warning about the incorrect parentage no longer appears. I don't know of any
other way to verify it without inspecting the code...
|
|
||
Comment 12•24 years ago
|
||
hmmmmnnn...okay, that sounds like a good way to do it. Er, at the risk of
sounding like a *complete* idiot, where do I get debug builds for Linux, Windows
and Mac?
|
|
Reporter | |
Comment 13•24 years ago
|
||
I'm note sure where you can get a ready-made debug build. It would probably be
best to just build your own. If you cannot build it, maybe somebody else
(Mozilla developer fo Netscape developer) could verify it? Sorry I don't have a
better suggestion :(
|
|
||
Comment 14•24 years ago
|
||
No, no that's a good suggestion and I appreciate it. Thanks Marc!
|
||
Comment 16•24 years ago
|
||
verified Build 2001081303T os:win95,mac8.6,winNT
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•