The browser dies (all windows that were open close) when I try to edit <a href="http://www.unixreview.com/development/articles/9908f1dw.shtml">this page</a>. I noticed that it happens right after the edit window opens, either when I move the mouse, or try to resize the window, etc. Regards, Jorge M.
yes I can reproduce this on linux...does not crash on windows...
WFM Linux 091908. Anyone else verify?
Worksforme on Windows NT today with my debug build: 2000091312
that is hands down one of the worst constructed web pages I have ever seen. There are close to a dozen html start and end tags interspersed within table elements, end form element that is misplaced, and other such things. Clearly an extremely malformed file. Granted we should not crash, but this is clearly an edge case. Will try to clean it up and attach to see if the cleaned up file crashes on linux
Whiteboard: [need info]
Target Milestone: M17 → M19
Setting bug status to New. Bugs whaich have been triaged to a target milestone should not be Unconfirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
no, this has not been confirmed, i indicated that we need information before confirmation, please leave the status as unconfirmed for just those reasons
This bug has a confirmation ------- Additional Comments From firstname.lastname@example.org 2000-09-13 14:42 ------- yes I can reproduce this on linux...does not crash on windows... and a Target Milestone. The Unconfirmed state is to protect developers from worthless bugs not to discriminate against those unfortunate bug reporters without a netscape.com email address. A bug which crashes us, under any circumstances, that has been reproduced should not sit in the Unconfirmed state. When _every_ bug starts off Unconfirmed (Including the scores of Invalid, Worksforme and Duplicate bugs filed by netscape empleyees) then I will agree that a bug should stay Unconfirmed until we have fully triaged it. But in this case we have a report which had sufficient information to reproduce a crash. I can see no reason why it should stay unconfirmed.
hey guys, Bugzilla is going haywire..I did not enter that last commment above. I have no idea how that got there....
I think Asa posted your earlier comment in the middle of his post to show that someone (you) confirmed the crash to exist...
ok, let me reiterate one more time -- as long as a bug is under investigation, and I have explicitly requested additional information -- leave it as unconfirmed -- need info means I am attempting to confirm the issue, regardless to what any other individual reports. It is unconfirmed until the root of the problem is found, by moving it to new or assigned, you just took it off my investigate radar. If you are not the 1. owner of the bug, or 2. someone who is helping to provide a reduced testcase and provided one -- leave the status alone.
I disagree that "It is unconfirmed until the root of the problem is found..." There are thousands of bugs filed every month which start off as New because the reporter happens to have a permission switch flipped on his/her Bugzilla Account. Hundreds of those bugs are written off as WFM, Invalid, and duplicate and most of the ones which are not bad don't start off with the root of the problem included in the report. There should be no difference between a well reported and reproduceable bug filed by a netscape contribuotor and a well reported and reproduceable bug filed by a non-netscape contributor. "by moving it to new or assigned, you just took it off my investigate radar." So you don't investigate bugs filed by people with the Can Confirm Bugzilla permission. Unconfirmed is an ineffective and impractical "needs investigation" radar. The Unconfirmed state was created to shield developers from what was expected to be a flood of poorly written bug reports that we thought would result from the exposure of Netscape's PR1. It was not created to put well written bugs filed by non-netscape contributors in a some other class from those filed by netscape employees. There is a large group of volunteers working in Bugzilla to keep the Unconfirmed state from becoming a black whole. We process hundreds of Unconfirmed bugs each week, clearing out duplicates, invalid and worksforme bugs and confirming and even testcasing good bugs so that developers can focus on fixes and not waste a lot of time looking at unhelpful bug reports. We aren't going to leave the status of Unconfirmed bugs alone. I apologize if I confused you by confirming this report and will try to ammend my Unconfirmed queries to exclude bugs where you have [need info] in the status whiteboard but I strongly disagree with your assertion that only an owner or someone willing to testcase a bug can Confirm it. This product would be in far worse shape than it is without the efforts of those contributors that you would exclude from the process.
moving to future, this needs to be reduced and tested before any recommendations can be made
Target Milestone: M19 → Future
accepting to get rid of that annoying bugzilla reminder
Status: NEW → ASSIGNED
Hmmm, the sample URL: http://www.unixreview.com/development/articles/9908f1dw.shtml is no longer available. I'll take this bug off of beppe's plate. If anyone can give me the page or something that causes the same crash, I'll debug it.
Assignee: beppe → kin
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla0.9.1
Move to Future and possibly resolving as Invalid at some future date if we can't find a file to reproduce this crash. Jorge Martinez--if you can reproduce it, please attach a file or provide a new URL. Thanks!
Target Milestone: mozilla0.9.1 → Future
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.