FTP message error window can get too big, should be a scrollable window

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
18 years ago
3 years ago

People

(Reporter: gerbilpower, Unassigned)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Created attachment 31173 [details]
Screenshot of oversized FTP alert window

Comment 2

18 years ago
--> networking:ftp for triage
Assignee: asa → dougt
Component: Browser-General → Networking: FTP
QA Contact: doronr → tever

Comment 3

18 years ago
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

Comment 4

18 years ago
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

Comment 5

18 years ago
Why don't we want scrollbars in an alert?

Updated

18 years ago
Target Milestone: --- → Future

Comment 6

18 years ago
  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.

Comment 7

18 years ago
  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.

Comment 8

18 years ago
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...

Comment 9

17 years ago
reassigning to bbaetz@cs.mcgill.ca.
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.

Updated

17 years ago
QA Contact: tever → benc

Comment 11

17 years ago
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

Comment 14

16 years ago
I looked at Communicator, and it doesn't show the error in the page, it does 
however, have a variable height error dialog.

Comment 15

11 years ago
mass reassigning to nobody.
Assignee: dougt → nobody
-etimedout
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.