Closed Bug 29749 Opened 24 years ago Closed 24 years ago

BORDER="false" converted to 0xFA, big border

Categories

(Core :: Layout, defect, P3)

defect

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 ...
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.
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")
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Changed component to Layout as this affects <IMG>, <FRAMESET>, and if
nsString::ToInteger or nsGenericHTMLElement::ParseValue is changed, many other
things.
Assignee: pollmann → rickg
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
*** Bug 29960 has been marked as a duplicate of this bug. ***
*** Bug 30214 has been marked as a duplicate of this bug. ***
Assignee: rickg → pollmann
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!
*** Bug 30490 has been marked as a duplicate of this bug. ***
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
Will test tomorrow to see when this regression occured.
*** Bug 28421 has been marked as a duplicate of this bug. ***
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
Putting on PDT+ for beta1. Please fix by 03/09
Whiteboard: [PDT+] w/b minus by 03/09
Adding relnote keyword in case fix doesn't take
Keywords: relnote
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
At least part of bug 30408 is a dup of this.
Fixed by readding (regressed) code that observers the user supplied radix.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Fixed in the March 08 build (2000030813).
Status: RESOLVED → VERIFIED
*** 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.