Closed Bug 49339 Opened 20 years ago Closed 20 years ago

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

Categories

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

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: chris, Assigned: kinmoz)

References

()

Details

(Keywords: helpwanted, Whiteboard: [nsbeta3+])

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
xpapps.  
Assignee: asa → ben
Component: Browser-General → XP Apps: GUI Features
QA Contact: doronr → sairuh
*** 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
Assignee: ben → pavlov
Keywords: nsbeta3, ui
*** 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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
still happens for me using linux 2000.08.29.08 opt comm bits. reopening.
Status: RESOLVED → REOPENED
Keywords: helpwanted
Resolution: WORKSFORME → ---
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.
Assignee: pavlov → beppe
Status: REOPENED → NEW
Component: XP Apps: GUI Features → Editor
QA Contact: sairuh → sujay
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.
Assignee: beppe → kin
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
Accepting bug.
Status: NEW → ASSIGNED
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
Status: ASSIGNED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
verified in 9/13 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.