Closed Bug 193122 Opened 22 years ago Closed 21 years ago

IMG with empty set width and height attributes crash browser

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: georg, Assigned: jdunn)

Details

Attachments

(1 file)

Testcase zipped
3.44 KB, application/octet-stream
Details
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.
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>
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....
Attached file 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.
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
WorksForMe (I can't reproduce on win2k)
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
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.
-> 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
Closed: 21 years ago
Resolution: --- → WORKSFORME
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.
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: