49339 - "Saving File" dialog doesn't initially show complete filename.

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Chris Brien]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20000814
BuildID:    20000081404

In the saving file dialog, it only initially displays the last seven characters
of the file you're downloading.
For example
Saving From:    ler.exe
         To:    ler.exe

instead of
Saving From:    mozilla-win32-installer.exe
         To:    mozilla-win32-installer.exe

Reproducible: Always
Steps to Reproduce:
1.Right click a file and choose "save link as".
2.Choose where to save the file.

Actual Results:  Saving file dailog only displayed ler.exe

Expected Results:  Should have displayed mozilla-win32-installer.exe

You can actually see the whole filename, it you drag-select it. It looks stupid
to start with as you can only see part of it.

Comment 1

[Jeffrey Baker]

Confirmed on Linux 2000-08-16.

Comment 2

[Asa Dotzler [:asa]]

xpapps.  

Comment 3

[Jeffrey Baker]

*** Bug 50259 has been marked as a duplicate of this bug. ***

Comment 4

[Mike Young]

I see this bug as well, but for me I only see the last letter of the file. p for
.zip files and z for .gz files. If you try to select the contents of the box by
dragging to the left, the contents come back into view, and don't go away.
Seen on Win32 8/23 build. Haven't yet checked Linux, but imagine it's the same.

Comment 5

[sairuh (rarely reading bugmail)]

pavlov, is this a problem with the file picker, or something else? when i repro
this on linux i get this console output:

WEBSHELL+ = 4
Error loading URL
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu.tar.gz:
804b0002 
-*- filepicker: CI: {c47de916-1dd1-11b2-8141-82507fa02b21}
-*- filepicker: IID:nsIFilePicker
nsIDOMWindow id value = {a6cf906b-15b3-11d2-932e-00805f8add32}
WEBSHELL+ = 5
we don't handle eBorderStyle_close yet... please fix me
WEBSHELL+ = 6
WEBSHELL- = 5
WEBSHELL- = 4
result native path = /u/sairuh/Tests/mozilla-i686-pc-linux-gnu.tar.gz

Comment 6

[R.K.Aa.]

*** Bug 50657 has been marked as a duplicate of this bug. ***

Comment 7

[Peter Trudelle]

I saw this a while ago, but can't repro using today's verification builds on any
platform.  Who owns the glue between the apps and the native pickers, anyway?
resolving as wfm, please reopen if you see again.

Comment 8

[sairuh (rarely reading bugmail)]

still happens for me using linux 2000.08.29.08 opt comm bits. reopening.

Comment 9

[Gilles Durys]

Works fine on M18 build 2000083008 Win32

Comment 10

[sairuh (rarely reading bugmail)]

i wonder if this is [now] just a linux filepicker issue? *shrug*

Comment 11

[Peter Trudelle]

I still can't reproduce this.  sairuh, do you have any new steps, or a
particular configuration that this happens in?    

Comment 12

[Stuart Parmenter]

I see it here...  this would have to be part of the saving code that is doing
this, not the filepicker.  this should really be assigned to bill I think, but I
can take a look at it if it gets nsbeta3+d (which I think it should)

Comment 13

[Stuart Parmenter]

oh wait. i'm wrong.  on linux, the text field seems to be scrolling over for no
reason.. let me look at it

Comment 14

[Stuart Parmenter]

i bet this is being caused by us inserting the text early on, and then the
textfield resizes?  is this an ender light problem?

Comment 15

[Peter Trudelle]

pav says this is Ender, reassigning.

Comment 16

[Simon Fraser [no longer active]]

Yes, we don't correctly scroll the contents of a textfield back into
view if the textfield is made wider. You can see this if you:

1. Open a browser window with long URL
2. Shrink the window horizonatally so tha the URL bar only shows part of the URL
3. Select to the end of the URL, so that it scrolls to the end
4. Make the browser window wide again. Note that we don't rescroll the contents
   of the URL bar to show more text. We should.

Comment 17

[kinmoz]

Accepting bug.

Comment 18

[kinmoz]

Checked in a fix:

   mozilla/layout/html/forms/src/nsGfxTextControlFrame2.cpp  revision 1.97
   mozilla/layout/html/forms/src/nsGfxTextControlFrame2.h    revision 1.31

We now scroll to the (0,0) position within the Text widget whenever the value is 
set.

r=[e-mail]

Comment 19

[sujay]

verified in 9/13 build.