When trying to gain access to a FTP server that is loaded, it sends error message that looks something like this: "FTP Error Could not login to FTP server [...] User anonymous access denied." In Netscape 4.xx, this shows up as a rendered page in the browser. In Mozilla, at least in build 2001041704, this shows up as a popup alert window. In some cases, the message being sent by the FTP server can be big, so the alert window in Mozilla gets very big also. In one case I observed, the window was nearly the height of my 1024x768 screen. Mozilla should render these FTP messages as scrollable windows instead to avoid problems with big messages. This was observed on Build 2001041704, Windows 98 SE.
--> networking:ftp for triage
Assignee: asa → dougt
Component: Browser-General → Networking: FTP
QA Contact: doronr → tever
I have nothing to do with the window sizes. I am using nsIPrompt and passing in a reasonable sized message string. Reassign to danm
Assignee: dougt → danm
HA HA HA! Alright Doug, we're not putting scrollbars in alert windows. How about truncating the "reasonably sized string" at the twentieth line or something?
Assignee: danm → dougt
Why don't we want scrollbars in an alert?
You ... you really want scrolling alerts? Two reasons. From a performance perspective, the extra frames and XBL bindings would slow down alert window creation time, and alerts are already too slow. We should be trying everything in our power to make alerts five times faster, and "everything in our power" starts with not slowing them down. Then, from a UI design perspective, call it a personal opinion, but I think alerts should be small and easily digested and have little to do with a Tolstoy novel. I can see an argument for a big scrolling message area window in nsIPrompt ... maybe ... I mean nsIPrompt hasn't been used for that before. And maybe, lacking a more suitable candidate, that's nsIPrompt::Alert. But in general terms if you're using Alert *I* feel you should make an effort to be terse, so that when the alert window pops up, nervous people won't be inclined to blurt "yah!" and fall out of their chairs. The message area, by the way, is just an html text field. What happens if somebody feeds Alert a block of <pre> text with really long lines? It's a small step from vertical scrollbars to horizontal, if you want Alert to be prepared to display absolutely anything you feed it. Not to mention (see me doing it anyway) that Alerts are intrinsically sized. Meaning that even if it had scrollbars it would try to not use them. Alright maybe there should be code to make sure that intrinsically sized windows will fit on your screen. But that implies that all windows -- I mean all windows -- should have scrollbars in them so if ungainly comes to monstrous we can ratchet their huge, world-devouring carcasses back down to a reasonable size. But my favourite solution is to make Alerts simple and quick, and that suggests users be circumspect about the message. There's a penalty of performance and usability to be paid for generality, and I think we already got it right.
Ooo. Not to mention (!) that alerts can have alternate implementations in embedding applications. We truly can't impose on embedders who want to override the nsIPrompt implementation a requirement to handle any arbitrary content. Alert needs to be implementable in terms of ::MessageBox.
heh. well, just to be clear, that alert text comes from the server, and I am not sure where I should truncate it. 20 lines - 30 lines? Since there really isn't any constraint on the nsIPrompt API, I just assume that I can pass you everything...
reassigning to firstname.lastname@example.org.
Assignee: dougt → bbaetz
I don't think that truncating is the correct solution. Given how the directory indexing works, and the need to support the xul viewer, displaying an html page isn't really possible at the moment. An API may fall out of doing work to show .message files and similar, though.
Is there some other place we could put the text in the window?
As was alredy noted, the FTP error could be dispayed instead of the page content (which is usually empty anyway if an error was returned), behaving just like HTTP.
I have no time to work on mozilla at the moment, so dougt is taking over FTP open ftp bugs -> him
Assignee: bbaetz → dougt
I looked at Communicator, and it doesn't show the error in the page, it does however, have a variable height error dialog.
mass reassigning to nobody.
Assignee: dougt → nobody
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.