Closed
Bug 29749
Opened 24 years ago
Closed 24 years ago
BORDER="false" converted to 0xFA, big border
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
VERIFIED
FIXED
People
(Reporter: sentinel, Assigned: rickg)
References
()
Details
(Keywords: relnote, Whiteboard: [PDT+] w/b minus by 03/09, fix in hand)
In 2000022716/Win98SE visiting the above page www.pingtool.com ... between the left frame specified at 155 pixels, and the right frame with * of the remaining width, is a blank white frame?/box?/something about 280 pixels or so wide. This does not show up in NS4.7 or IE5.5 and I wouldn't expect it to show up in Mozilla either ...
Comment 1•24 years ago
|
||
Believe it or not, the problem is this: <FRAMESET... BORDER="FALSE" ...> This "false" is being interpreted as a hexidecimal number "fa" or 230 pixels. The border attribute is deprecated. Also, it is supposed to get a numeric argument not a boolean one, per the HTML 4 spec: http://www.w3.org/TR/REC-html40/struct/objects.html#adef-border-IMG Since this is invalid use of a depricated tag, I'm going to close this bug out as invalid. If you would like it fixed for the sake of backwards compatability, please reopen, thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Backwards compatibility is always nice, but so is an up-to-spec webpage. That really is an interesting one, i never would have thought "FALSE" to have that effect... Notified the owner, thanks.
Comment 3•24 years ago
|
||
I'm cc'ing rickg on this bug as he might find it interesting, and I got another one just like it today (bug 28820). Is there a way to specify string conversion such that non-numeric strings get converted to "0" by default? (The web site in question is not only out of spec, but the "border=false" should have no effect in existing browsers either, which would be expecting something along the lines of "border=0")
Comment 4•24 years ago
|
||
Forwarding to rickg for consideration.
Status: RESOLVED → UNCONFIRMED
Component: HTMLFrames → Layout
OS: Windows 98 → All
Hardware: PC → All
Resolution: INVALID → ---
Summary: Blank White Box Stuck Between 2 Frames → BORDER="false" converted to 0xFA
Updated•24 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•24 years ago
|
||
Changed component to Layout as this affects <IMG>, <FRAMESET>, and if nsString::ToInteger or nsGenericHTMLElement::ParseValue is changed, many other things.
Assignee: pollmann → rickg
Comment 6•24 years ago
|
||
Adding keywords as I got yet another near dup of this today on bug 1199
Summary: BORDER="false" converted to 0xFA → BORDER="false" converted to 0xFA, big border
Updated•24 years ago
|
Assignee: rickg → pollmann
Comment 9•24 years ago
|
||
Taking this back from Rick, per our conversation. I'll try to find a way to special-case border='false' because ToInteger doesn't seem to be the right place to do it. Thanks Rick!
Comment 10•24 years ago
|
||
*** Bug 30490 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
In light of the number of very recent duplicates of this bug, I bet this is a recent regression. If so, we should nominate this for beta1 as it is high visibility.
Status: NEW → ASSIGNED
Comment 12•24 years ago
|
||
Will test tomorrow to see when this regression occured.
Comment 13•24 years ago
|
||
*** Bug 28421 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
This seems to be a highly visible and recent regression. (witness the number of dups in the short time M14 has been out) I'm nominating a fix for beta1, though I don't yet know what or how big the fix will be. :S
Keywords: beta1
Comment 15•24 years ago
|
||
Putting on PDT+ for beta1. Please fix by 03/09
Whiteboard: [PDT+] w/b minus by 03/09
Comment 17•24 years ago
|
||
Rick came up with a fix for this bug. I've tested on each of these cases and there is no longer a larger border around the image/frame. Reassigning to Rick. (I tested on Linux and Solaris)
Assignee: pollmann → rickg
Status: ASSIGNED → NEW
Whiteboard: [PDT+] w/b minus by 03/09 → [PDT+] w/b minus by 03/09, fix in hand
Comment 18•24 years ago
|
||
At least part of bug 30408 is a dup of this.
Assignee | ||
Comment 19•24 years ago
|
||
Fixed by readding (regressed) code that observers the user supplied radix.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 21•24 years ago
|
||
*** Bug 29177 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•