Closed
Bug 100595
Opened 23 years ago
Closed 22 years ago
crash [@ nsMultiMixedConv::FindToken] [was: sandiegozoo.org - this site crashes the browser, every time]
Categories
(Core :: Networking, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla1.0.1
People
(Reporter: pete, Assigned: darin.moz)
References
()
Details
(Keywords: crash, testcase, topcrash+, Whiteboard: [adt1 RTM][ETA 05/28])
Crash Data
Attachments
(7 files)
994 bytes,
text/html
|
Details | |
12.13 KB,
application/octet-stream
|
Details | |
12.32 KB,
application/octet-stream
|
Details | |
540 bytes,
patch
|
dougt
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
2.22 KB,
text/plain
|
Details | |
3.37 KB,
text/plain
|
Details | |
13.18 KB,
patch
|
dougt
:
review+
rpotts
:
superreview+
chofmann
:
approval+
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4+) Gecko/20010917 BuildID: 2001091703 I've tried going to this site through a link, and just typing it in to the address bar. either way, it crashes before anything is displayed. Reproducible: Always Steps to Reproduce: 1. visit this link, http://www.sandiegozoo.org/special/pandas/pandacam/index.html
Comment 1•23 years ago
|
||
wfm 2001091910 linux
Comment 2•23 years ago
|
||
Works for me: Windows NT SP6a, build 2001091703
i've just retried the link that was crashing for me, and it does work for me now as well. no crash. perhaps the only way to track down the problem is looking over the two "Talkback" reports that were sent in when the browser died?
just to make me look foolish, mozilla struck again. right after my previous comment, which mentioned it looked like it was working for me, i hit the link one more time. it crashed the browser on me and i sent in the talkback info. is there anything i should to when viewing this site that would help anyone isolate this bug?
Comment 5•23 years ago
|
||
reproter: go to mozilladir\components, open talkback.exe and get the talkbackid's and post them here, thanks
Here are the 3 talkback crash reports. the last two were the ones i got in the morning, the first one was from later that day. TB35618502Q TB35603828G TB35603735Y
Comment 7•23 years ago
|
||
Incident ID 35618502 Stack Signature nsMultiMixedConv::FindToken 4c0627e3 Bug ID Trigger Time 2001-09-19 17:23:52 Email Address pete@visionart.com User Comments I've already filed this as a bug, just when it seems it was working for everyone, it crashed on me again. Seems to happen almost every time, but turns out it did work for me once? Build ID 2001091709 Product ID MozillaTrunk Platform ID Win32 Trigger Reason Access violation Stack Trace nsMultiMixedConv::FindToken [d:\builds\seamonkey\mozilla\netwerk\streamconv\converters\nsMultiMixedConv.cpp, line 973] nsMultiMixedConv::OnDataAvailable [d:\builds\seamonkey\mozilla\netwerk\streamconv\converters\nsMultiMixedConv.cpp, line 504] ProxyListener::OnDataAvailable [d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp, line 402] nsStreamListenerTee::OnDataAvailable [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerTee.cpp, line 57] nsHttpChannel::OnDataAvailable [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2255] nsOnDataAvailableEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerProxy.cpp, line 188] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1072] 0x0017000f
Assignee: asa → neeti
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
QA Contact: doronr → benc
Assignee | ||
Comment 9•23 years ago
|
||
using a 20011001 build under linux, i cannot repro the crash. instead we just never load the zoocam. using telnet i tried to load the zoocam page, but the server never responded... it just closed the connection. so, it looks like reproducing this bug is going to be difficult. reporter: can you still reproduce this crash using a recent nightly build?
Reporter | ||
Comment 10•23 years ago
|
||
yes, it still crashes. an all white blank page appears, then 2 seconds later it crashes. this is with build #2001100203, from a couple days ago. i sent the talkback info in, it is incident number TB36276774G.
Comment 11•23 years ago
|
||
*** Bug 98184 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
*** Bug 103407 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Summary: this site crashes the browser, every time → this site crashes the browser, every time [@nsMultiMixedConv::FindToken]
Assignee | ||
Comment 13•23 years ago
|
||
i'll try to investigate this for 0.9.6
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6
Assignee | ||
Comment 14•23 years ago
|
||
ok, i was able to repro this using an optimized winnt build... here's the packet that causes us trouble: T 216.120.90.235:80 -> 208.12.39.149:2069 [AP] HTTP/1.1 200 OK..Date: Thu, 11 Oct 2001 00:05:27 GMT..Server: Apache/1 .3.9 (Unix)..pragma: no-cache..cache-control: private..Connection: clo se..Transfer-Encoding: chunked..Content-Type: multipart/x-mixed-replac e;boundary=CamZoneRS....123..HTTP/1.1 200 OK..Date: Thu, 11 Oct 2001 0 0:05:27 GMT..Server: Apache/1.3.9 (Unix)..pragma: no-cache..cache-cont rol: private..Connection: close..Transfer-Encoding: chunked, chunked.. Content-Type: multipart/x-mixed-replace;boundary=CamZoneRS....Content- type: image/jpeg.Content-length: 13810....35f2........JFIF............ .C................................... $.' ",#..(7),01444.'9=82<.342... C...........2!.!22222222222222222222222222222222222222222222222222.... ....@.."............................................................}. .......!1A..Qa."q.2....#B...R..$3br........%&'()*456789:CDEFGHIJSTUVWX YZcdefghijstuvwxyz.................................................... ...................................................................... ....w.......!1..AQ.aq."2...B.....#3R..br...$4.%.....&'()*56789:CDEFGHI JSTUVWXYZcdefghijstuvwxyz............................................. .......................................?...G&..j.=*..2...>..w..I9..j.. RY.Y.^.F.4....f...;a... {..ü.y...b.Jk. .qU........`..p@?Z..}j\.;XE.H:. ji..7...PK$p'.,....b.....p....F.......$.......q...:,......p)...2.Io..P p..P..O.Gcd.........._u.....q.q>..k.?...i$.U.....E there are actually a couple major problems with this packet. first, the server claims that the data will be sent using a chunked transfer encoding, but it doesn't do the chunked encoding properly. it appears that each section of the multipart document is individually chunked. this does not follow the specifications for the chunked transfer encoding [see RFC2616]. the server should instead apply the chunked transfer encoding to the multipart document. this would achieve the desired (streaming) effect. somehow, IE6 manages to handle this very badly formed document. i don't think the effort required to support this broken server will be worth it. -> evangelism
Assignee: darin → bclary
Status: ASSIGNED → NEW
Component: Networking → English: US
Product: Browser → Tech Evangelism
QA Contact: benc → zach
Version: other → unspecified
Assignee | ||
Comment 15•23 years ago
|
||
actually, it appears that the server is not serving IE6 a multipart document. i'm not sure why the server is not sending us the same kind of content... oh, but upon inspection of the html source, it appears that the code is requesting a different URL when used with IE. and, with Netscape4x, the server does not send the Transfer-Encoding: chunked header, so the 4x doesn't have any trouble loading the page. so, it appears that the server just decides to send junk to mozilla :-/
Comment 16•23 years ago
|
||
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011 crash. Talkback ID #TB36635201G Recommend setting OS to All.
Comment 17•23 years ago
|
||
ok, this is a problem with that server but I think mozilla should not crash !
Comment 18•23 years ago
|
||
we need to spawn a new bug off to deal with the crash and evang this site
Summary: this site crashes the browser, every time [@nsMultiMixedConv::FindToken] → sandiegozoo.org - this site crashes the browser, every time [@nsMultiMixedConv::FindToken]
Comment 19•23 years ago
|
||
Darin, I think we can evangelism the site although getting a Server to change it's responses has more inertia than getting an author to change html. Regardless of the validity of the Server response, I agree that Mozilla *should not* crash. Please take this bug back as a product bug. I have created bug 104601 to handle the evangelism of the site and am giving this bug back to you.
Assignee: bclary → darin
Component: English: US → Networking
Product: Tech Evangelism → Browser
QA Contact: zach → benc
Version: unspecified → other
Assignee | ||
Comment 20•23 years ago
|
||
ok... makes sense.
Comment 21•23 years ago
|
||
View Source Works. view-source:http://www.sandiegozoo.org/special/pandas/pandacam/index.html Maybe that'll help us figure out if this is coming from a crash we already know about. :D
Comment 22•23 years ago
|
||
Disable JavaScript, page renders, no crash. There's a lot of script in this page; the script is definitely responsible. DOM, ECMA?
Comment 23•23 years ago
|
||
This is too good for me to miss. :D
Comment 24•23 years ago
|
||
Ok, here are the possible suspects. First script: <script language="JavaScript"> <!-- hide from JavaScript-challenged browsers function openWindow(url, name) { popupWin = window.open (url,'name', 'width=200,height=250,left=left');popupWin.focus(); } // done hiding --> </script> Second script: <script language="JavaScript"> <!-- hide me from antiquated technology function open_window(url) { mywin = window.open (url,"mainadd",'toolbar=0,location=0,directories=0,status=0,menubar=0,scrollbars =1,resizable=1,width=300,height=300,alwaysRaised=yes'); mywin.focus(); } // stop hiding me --> </script> Third script: <script language=JavaScript> var framecount=0 var maxframes=300 function msiestreamer(theImage) { var now = new Date() ++framecount secs = now.getTime() if (framecount <= maxframes) { var camzone="http://zoorr.camzone.com/cams/zoocam/.camzone-ie?87+" + framecount + "+" +secs theImage.src=camzone } else { framecount=-1 return } } if (navigator.appName == "Netscape") document.write('<img src="http://zoorr.camzone.com/cams/zoocam/.camzone?87" border=3 width=320 height=240 alt="CamZone">') else document.write('<img NAME="ieanim" src="http://www.camzone.com/images/intro.jpg" width="320" height="240" alt="CamZone" border="3" onLoad="msiestreamer(this)">') </SCRIPT> Another possible (highly unlikely): <a href="javascript:open_window('faqs.html')"><font size="1">Problems viewing our cam?</font></a> And again (unlikely) <script> <!-- This script and many more are available free online at --> <!-- The JavaScript Source!! http://javascript.internet.com --> <!-- Begin if (window != top) top.location.href = location.href; // End --></script> I haven't checked event handlers. But considering the page crashes before we see anything, I think we can rule out most of them.
Comment 25•23 years ago
|
||
Comment 26•23 years ago
|
||
TB36970299Y on the crasher script. All of a sudden, though, I'm having a lot of trouble trying to reproduce it.
Comment 27•23 years ago
|
||
Something very unusual just happened. About five minutes after I posted the attached crash case, my browser stopped crashing. I was tinkering around, trying to reduce the testcase even further. So, for the moment, can someone besides me attempt to reconfirm the original testcase for this bug as still crashing the nightlies? If so, can that person also attempt to confirm my own crash case? For me, the documents now load normally. An image from their videocam comes up nonexistent. In the meantime I just picked up another clue. http://zoorr.camzone.com/cams/zoocam/.camzone?87 If you try to download that, Mozilla reports mime-type application/octet-stream. The image tag isn't supposed to accept that, I know. Could that be it?
Comment 28•23 years ago
|
||
fwiw, wfm win98 2001101909 I tried the page and the attachment, several reloads ...
Comment 29•23 years ago
|
||
Ok, URL link just crashed on me again. First sequence: (a) Loaded page, image came up fine. (b) Reloaded, image never showed. (c) Reloaded, crash. Came back to this bug, went to the link again, crash. Came back to the link, was typing this up in another tab, about one minute later, crash. All this a little before 5am, same nightly as before. Others having trouble reproducing at this stage. They have confirmed image sighted and application/octet-stream mimetype, which is an unusual combination. Talkback ID's TB36971416X TB36971450W TB36971542E Very unusual.
Comment 30•23 years ago
|
||
when viewing http://zoorr.camzone.com/cams/zoocam/.camzone?87 the first time, an image appears in the navigator window and I am asked to open/save the type application/octet-stream. If I reload, I only see "http://zoorr.camzone.com/cams/zoocam/.camzone?87" displayed in the navigator window, and am again asked to open/save. Then, in the history list, if I put that url in, the comment next to in italics says, "Image 566553664x56142144 pixels". Any time I go back to the main san diego zoo page and then return to the image page, it loads. If I hit refresh from the .camzone page, it just gives me the URL. This was very consistent. Here's my help:about Mozzila info. Mozilla 0.9.5 Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011 I'm using 98SE, if it matters, and I have not upgraded IE at all, so IE 5.00-264.3500. No service packs, either (for the OS, office, or IE). I don't have DevStudio installed, so system DLLs should all be virgin.
Comment 31•23 years ago
|
||
Comment 32•23 years ago
|
||
Oh, and quick update: If you get the image to display at http://zoorr.camzone.com/cams/zoocam/.camzone?87 and then press back (presuming back goes to the main panda cam page), then the image will display in the panda cam page, presumably showing what they intended.
Comment 33•23 years ago
|
||
still win98 101909 I'm seeing what infinite_8_monkey is seeing, but have a bit more info here ... The FIRST time I visited this site, the application/octet-stream file that the server is trying to send (filename is .camzone) has a header of: n-content-type&to=*/*eg On every subsequent visit, the .camzone file (same MIME type) has a different header: Content-type: image/jpeg Btw, the image sizes are different every time I reload. Here is a short list of a few image sizes: 9540416x9479856 9624896x9490592 9684128x9492528 9743440x9622608 9809056x9309168 (don't bother whipping out the calculator, there doesn't seem to be any pattern.) After reloading this page many, many times, I eventually can no longer connect to the site. I just get a status message of "Connecting to zoorr.camzone.com" and it eventually times out ... When it does time out, I get no download window or anything else (note, I also get no error message.) I can still connect to other sites just fine. If I restart mozilla, I can reconnect to the site & start the process again, where the image shows up properly. I will attach the two different .camzone files if someone decides this is necessary.
Comment 34•23 years ago
|
||
Well, Darin, Ben, I hope you have enough to track down this bug. I gave up hope on this bug at 4:15 am. :) Based on the followup reports, I believe I can conclusively state faulty JavaScript or DOM code is not at fault here. This is a reversal of the opinion I held earlier. That being said, this is still a sporadic bug. Given the variable results we've had in downloading the file associated with the img tag, I think it should be possible to recreate the conditions which cause this crash 100% of the time. It's going to require some server-side code -- something I'm actually not qualified enough on. I've added the two contributors directly after me as cc's. They helped out a lot in irc, helping me to reconfirm first the site's sudden lack of crashing, then the wacky server image information. Mr. Schuette tells me, although this is as yet unconfirmed, he was experiencing damage with his profiles and associated histories after the crash. He was unable to consistently reproduce this effect, and no one else has as yet, among the three of us, seen the same. -- quote -- I'm to the point now where if I completely exit mozilla, and come back, the link would do nothing ... no download window, no nothing. So I cleared my disk cache, exited, restarted. ... Same thing ... nothing from that link ... I tried to go into my history to delete it, and ... I can't. Not only that, I can't delete any of my histroy items. ... So I exited, ran profilemanager, and created a new profile .... the new profile can read the image once, just like I could with the other profile ... and then the same functoinality ... ... now the interesting thing is, if I delete the item from my history and reload, the image shows properly again ... -- /quote -- Also, this just popped up, confirmed, while I wrote this out: -- quote -- (monkey)ok, so if I take the octest-stream that mozilla saves, strip off everything before the jpg header, then save it as a .jpg file, then mozilla will load it properly. (Schuette) yep. that's what I did. (monkey)I would suggest that the problem is in the jpeg handling code, dealing with this random crap, whatever it is... Or at least that's a reasonable place to look... (Schuette)The jpg file sequence begins with 0A 0A ... strip off everything up to that, you'll have a valid jpg remove the first 45 bytes (so the first bytes are 0A 0A 00 20) from the Content-type: image/jpg file, and you have a valid .jpg .. -- /quote -- -- quote -- (Schuette) further into the 2nd file than I looked before (in my other comment), there is a header for application/x-unknown-content-type .... the file I referred to as "n-content-type&to=*/*" has the application/x-unknown-content-type further into the header .... -- /quote -- We're currently continuing this debate in #mozillazine. However, I've opened up an alternate channel, #bug100595, just in case the #mozillazine crowd wants to punt us to the side. :)
Comment 35•23 years ago
|
||
Comment 36•23 years ago
|
||
We now have a 100% reproducible testcase. But it's not fun at first. (1) Make sure you're running this on a localhost server with perl installed. (2) Unzip the two files in the testcase, such that breakmoz.cgi is in your cgi-bin directory. (3) Adjust the shebang in line 1 to match the path to your perl interpreter as needed. (4) Edit the image path as given in lines 5 and 7 to point directly to the file. (5) Navigate in Mozilla through your http://localhost to breakmoz.cgi and execute the script. "This browser will self-destruct in five seconds. Good luck, Ethan." If anyone needs help downloading and running a testbed Apache server, I recommend the Firepages phpdev4 build, available at http://www.firepages.com.au/devindex.htm .
Keywords: testcase
Comment 37•23 years ago
|
||
I'm sorry, I need to clarify for the people who will attempt fixing this bug what happened, in one sentence. The offending site is sending a videostream of multiple jpeg frames to an HTML <img /> tag. This tag is not designed to take multiple jpeg images, only one. From what I gather in the context (and I welcome monkey and Mike Schuette to correct me on this), the multiple mime-types are what causes this topcrash. Expected results: A broken image. Browser ignores the datastream, possibly presenting the first image in the datastream and closing the rest of the datastream immediately. The new testcase, which monkey designed, presents the multiple mimetypes to the browser via HTTP, where each individual "slide" is a copy of the original frame. Based on this summary, I would recommend the HTML parser attempt to handle this incompatibility.
Considering the stack trace and Darin's comments above, I think that description of the problem is wrong.
Assignee | ||
Comment 39•23 years ago
|
||
yes, exactly. this is a case in which we should evangelize the server to NOT send junk to mozilla. also, a bclary points out, we should make sure mozilla doesn't crash, even when sent junk. a null check in the multipart stream converter is probably all that is needed.
Status: NEW → ASSIGNED
Comment 40•23 years ago
|
||
their HTTP transaction is pretty bad with embedded newlines. In any case I think I can make it not crash. (taking over)
Assignee: darin → gagan
Status: ASSIGNED → NEW
Comment 41•23 years ago
|
||
Comment 42•23 years ago
|
||
The last patch fixes the crash. Essentially when we prepend the boundary to the buffer we blow away the buffer (and cursor was still pointing to it) With this fix, the cursor starts to point at the correct buffer and hence not crash trying to parse junk (freed up) data. Darin/Doug r,sr please.
Status: NEW → ASSIGNED
Comment 43•23 years ago
|
||
Comment on attachment 55804 [details] [diff] [review] patch to prevent the crash needed to reset the cursor to point to the new buffer.
Assignee | ||
Comment 44•23 years ago
|
||
Comment on attachment 55804 [details] [diff] [review] patch to prevent the crash sr=darin ...nice work tracking this down! please add a comment to the patch to indicate the importance of that line :)
Attachment #55804 -
Flags: superreview+
Comment 45•23 years ago
|
||
Comment on attachment 55804 [details] [diff] [review] patch to prevent the crash nit - you could do: cursor = tmp = buffer;
Attachment #55804 -
Flags: review+
Comment 46•23 years ago
|
||
doug: I could! But I won't... cuz I like things a little elaborate :) darin: I will add that comment when I check it in. both: thanks for the quick r/sr
Comment 47•23 years ago
|
||
checked in version 1.67 of nsMultiMixedConv.cpp
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 48•23 years ago
|
||
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5+) Gecko/20011102 Latest nightly is now showing no crash in the testcase I submitted above. Nice. (Reported from IE6)
Comment 49•23 years ago
|
||
Per discussion in #mozillazine, taking the initiative to mark VERIFIED. :)
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 50•22 years ago
|
||
*** Bug 131761 has been marked as a duplicate of this bug. ***
Comment 51•22 years ago
|
||
I looks like this one may still have some issues.
Comment 52•22 years ago
|
||
I just attached talkback comments from recent crashes whose signature matches the one in this bug. M099 and N622 crashes report a number of webcam sites (like the crashes in this bug). The Trunk crashes are something else. Judging from the pain of the previous fix I am wary of reopening this one. Esp. if the fixes need to be site specific. Darin, Gagan, please comment and reopen if necessary. Thanks.
Assignee | ||
Comment 53•22 years ago
|
||
greer: do any of those crash reports include stack traces? is there any common failure point? this could either be a new multipart stream converter problem or some problem in image lib. thx!
Comment 54•22 years ago
|
||
Darin, here are the latest crashes at this signature from Trunk and M1.0 Branch builds. The stacks resemble the one in Asa's commnt #7. They differ from each other in the third frame, one going through the image loader and the other through the uri loader. Digging in the detailed links (included in the attachment below each stack) Blake's crash says it was the result of a bad data block size (null).
Assignee | ||
Comment 55•22 years ago
|
||
ok, reopening to investigate...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 57•22 years ago
|
||
greer: should the topcrash keyword stay?
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla1.0.1
Comment 58•22 years ago
|
||
We need to keep the topcrash keyword for our tracking. The summary might be out of date however.
Assignee | ||
Updated•22 years ago
|
Summary: sandiegozoo.org - this site crashes the browser, every time [@nsMultiMixedConv::FindToken] → crash @nsMultiMixedConv::FindToken [was: sandiegozoo.org - this site crashes the browser, every time]
Comment 59•22 years ago
|
||
See also bug 42224 for problems with nsMultiMixedConv / JPEG push
Comment 60•22 years ago
|
||
*** Bug 99262 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.0.1 → ---
Assignee | ||
Comment 61•22 years ago
|
||
talkback incident 6259787 shows that this is still happening with the very latest 1.0 branch builds. targeting mozilla 1.0.1
Whiteboard: [adt1 RTM]
Target Milestone: --- → mozilla1.0.1
Comment 62•22 years ago
|
||
Updating URL to http://webcam315.cede.psu.edu as original one no longer uses multipart-mixed JPEG streaming, but rather javascript to "pull" individual frames.
Assignee | ||
Comment 63•22 years ago
|
||
so, i spent some time browsing through the talkback data, and i noticed that the aLen parameter passed into FindToken is almost always something very very large... usually something like: PRUint32(-1) or PRUint32(-5). this indicates that the variable bufLen in OnDataAvailable is getting incorrectly tweaked. investigating...
Assignee | ||
Comment 64•22 years ago
|
||
this patch is mostly cleanup, but i believe it fixes a number of places where we were possibly accessing an array beyond its bounds. i've also removed some buffer allocations and copies, which should help with performance.
Comment 65•22 years ago
|
||
I've been streaming 3 cams simultaneously for about 20 minutes now (reloading when broken or stopped), and there have been no crashes at all: http://webcam315.cede.psu.edu/view/view.shtml http://dormcam.mine.nu:8080/moztest.html http://engwear.org/1999/frosh/fungja/push.html
Comment 66•22 years ago
|
||
(with darin's patch from comment #64 ) sorry for spam...
Assignee | ||
Comment 67•22 years ago
|
||
WD: great.. thx for the feedback!
Comment 68•22 years ago
|
||
Comment on attachment 84369 [details] [diff] [review] v1 patch (multipart converter cleanup) looks good. I was most worried about breaking byte-range's, but that appears to be working properly. r=dougt. please notify the plugin's team about this change. Have them run regression tests against acrobat.
Attachment #84369 -
Flags: review+
Comment 69•22 years ago
|
||
Comment on attachment 84369 [details] [diff] [review] v1 patch (multipart converter cleanup) sr=rpotts@netscape.com
Attachment #84369 -
Flags: superreview+
Comment 71•22 years ago
|
||
Resolving as FIXED based on Darin's comment #70 From Darin Fisher, that this is fixed on the trunk. benc - Can you pls verify this on the trunk, and ensure it introduced no regressions. thanks!
Blocks: 143047
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Whiteboard: [adt1 RTM][fixed trunk] → [adt1 RTM][fixed trunk] [ETA 05/28]
Comment 72•22 years ago
|
||
Making this topcrash+ since we have a testcase and it has been fixed on the Trunk.
Comment 73•22 years ago
|
||
Is this Windows-only, or do I need to verify more platforms?
Comment 74•22 years ago
|
||
adt1.0.1+ (on ADT's behalf) for checkin to the 1.0 branch, pending Driver's approval.
Comment 75•22 years ago
|
||
Ben: From looking at Talkback data, this looks like to be a Windows only crash.
Assignee | ||
Comment 76•22 years ago
|
||
i think that's because we have more windows testers. this crash could have easily occured under linux... the related code is completely cross-platform.
Assignee | ||
Comment 77•22 years ago
|
||
reopening to make this easier for me to track... i don't want this to miss 1.0.1 on account of not being on my radar.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•22 years ago
|
Status: REOPENED → ASSIGNED
Comment 78•22 years ago
|
||
Comment on attachment 84369 [details] [diff] [review] v1 patch (multipart converter cleanup) a=chofmann for 1.0.1
Attachment #84369 -
Flags: approval+
Comment 79•22 years ago
|
||
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1" keyword and add the "fixed1.0.1" keyword." in the comments.
Updated•22 years ago
|
Keywords: mozilla1.0.1 → mozilla1.0.1+
Assignee | ||
Comment 80•22 years ago
|
||
fixed-on-branch
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•22 years ago
|
Keywords: fixed1.0.1
Whiteboard: [adt1 RTM][fixed trunk] [ETA 05/28] → [adt1 RTM][ETA 05/28]
Assignee | ||
Updated•22 years ago
|
Keywords: mozilla1.0.1+
Comment 81•22 years ago
|
||
Verified per Talkback. This one isn't showing up in post checkin data.
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Crash Signature: [@ nsMultiMixedConv::FindToken]
You need to log in
before you can comment on or make changes to this bug.
Description
•