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.

Confirmed on Linux 2000-08-16.

xpapps.

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

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.

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

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

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.

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

Works fine on M18 build 2000083008 Win32

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

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

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)

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

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

pav says this is Ender, reassigning.

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.

Accepting bug.

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=sfraser@netscape.com

verified in 9/13 build.