IMG with empty set width and height attributes crash browser

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
16 years ago
15 years ago

People

(Reporter: georg, Assigned: jdunn)

Tracking

Trunk
Future
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

3.44 KB, application/octet-stream
Details
(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030122
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030122

<img href="/images/bild/3.jpg" type="image/jpeg" alt="Test" width="" height="">

This crashes Mozilla. If I fill in the numerical values for width and height,
the crashes disappear. I did not jet check, wheteher the crash remains, if I
keep width and height empty but replace href by src

Tested with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030122

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
(Reporter)

Comment 1

16 years ago
The test case (I know that this is invalid)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 //EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html><head><title></title>
<link href="/css/layout.css" type="text/css" rel="stylesheet">
<link href="/css/color.css" type="text/css" rel="stylesheet">
</head>
<body>
<img href="/images/bild/3.jpg" type="image/jpeg" alt="Test" width="" height="">

</body>
</html>
(Reporter)

Comment 2

16 years ago
It also crashes, if I rename the wrong href attribute to src.

<img src="/images/bild/3.jpg" type="image/jpeg" alt="Test" width="" height="">

The crash seems to relate only the invalid values of width and height.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 //EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html><head><title></title>
<link href="/css/layout.css" type="text/css" rel="stylesheet">
<link href="/css/color.css" type="text/css" rel="stylesheet">
</head>
<body>
<img src="/images/bild/3.jpg" type="image/jpeg" alt="Test" width="" height="">

</body>
</html>
Could you attach a crashing testcase to this bug, or make it available on a
webpage, so that it can be easily tested?
worksforme, current linux trunk build....
(Reporter)

Comment 5

16 years ago
Created attachment 114410 [details]
Testcase zipped

This is a static test case, which also crashes when using pseudo protocol
file:///

The testcase contains two stylesheets (they might be irrelevant), a small image
and a small html document.

Comment 6

16 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

The page renders fine, the image appears at normal size
(Assignee)

Comment 7

16 years ago
WorksForMe (I can't reproduce on win2k)
(Assignee)

Comment 8

16 years ago
marking target, right now I am looking out till 1.4 and currently 
I don't plan on looking at this till afterwards.

Can you test this against 1.3b (the released version?) and see
if you can still reproduce this?
Target Milestone: --- → Future
(Reporter)

Comment 9

16 years ago
Testest now with Mozilla 1.3b [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.3b) Gecko/20030223], which runs without crash.

The bug seems to relate only to one or a few nightlies.

Comment 10

15 years ago
-> WFM (I also tested it)

Georg, it would be nice if you resolved the bug yourself when it works for you
and nobody else can reproduce it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 11

15 years ago
If we don't know, what caused the bug, then we never can grow up from WFM to
FIXED, because we don't know whether it is fixed or simply does not occure for
other reasons.

I also can not test with the original equipment because I'm no longer employee
of that company. The only I can say today is WFM. i guess this will be the final
state of this bug.

WFM does not really satisfy, but this is reality on living projects. If a bug is
fixed occasionally, then it rests in peace for ever as WFM. If a bug is not
fixed but occasionally disabled, then it also pauses as WFM but it may wake up,
if it is ocassionally enabled later again. A bug with unknown reason never can
be verified as FIXED. As long as the reason is unknown, the highest possible
level for the bug is WFM. This is the actual state. A change to this state can
only be made, if some one can reproduce the bug and identify the reason.

I think we should not waste our rare time for a bug, where all people say WFM on
actual builds, which is probably fixed, but can not be verified as fixed because
the reason of the bug is unknown.

Comment 12

15 years ago
Georg: ummm... yes, what you say is exactly what I meant. 
I'm not sure if thought I had a different opinion, but well, yes, this bug is
now WFM (because open bugs that never happen only mess up bugzilla and hide the
real ones) and can be reopened if it is seen again.
Of course the resolution is not FIXED because it is not known what possibly
fixed it. But this can be verified as WFM when nobody sees it for quite some time.
(Reporter)

Comment 13

15 years ago
Do I missunderstand the VERIFIED state?

I understand the VERIFIED state as "the bug is fixed and the fix is verified to
really fix the bug and not just to work around the bug". This is something I can
not verify.

The only thing I can say is, that without the original equipment (using a
specific build) I can not reproduce the bug. This situation is well expressed in
WFM. There is no new knowledge to change the state from WFM to VERIFIED. There
is also no new knowledge to reopen the bug. I think the actual WFM state is the
best. So I don't see any reason to change it neither downwards to OPEN nor
upwards to VERIFIED.
You need to log in before you can comment on or make changes to this bug.