Closed Bug 87831 Opened 23 years ago Closed 23 years ago

Fizilla unable to run (non alpha-numeric characters)

Categories

(Core :: Networking: File, defect, P3)

Product:
Core
Component:
Networking: File
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 95481
Milestone:
mozilla0.9.6

People

(Reporter: jnp, Assigned: ccarlen)

References

Details

(Keywords: hang, Whiteboard: [OSX], PDT+, FIXED IN TRUNK, [BRANCH ETA 09/28])

Attachments

(2 files, 2 obsolete files)

updated after testing with Japanese
17.85 KB, patch
Details | Diff | Splinter Review
JA test chars on Mac OS X
1.13 KB, text/plain
Details 
(build 6_13_01)

If system volume (only 1 volume) is named '•' (filled bullet) Fizilla is unable to run and stops abruptly.

Renaming volume to e.g. 'a' enables Fizilla to run.

However, renaming back to '•' (filled bullet) after the first run, seems to hang the system. The icons appears in the dock even if the application is not running, it is not visible in 'force quit' either.
cc: a few folks that might be able to help.
a stack trace would probably be very useful. per pinkerton i would have given 
this to sdagely but i think it's probably a file or nspr issue.
Assignee: asa → dougt
Component: Browser-General → Networking: File
QA Contact: doronr → tever
Target Milestone: --- → Future
does this happen with OS9? if so, we really need to fix this. Even if it doesn't, 
'future' isn't really an acceptable milestone for something like this.

This does not happen on OS 9

I wonder if it is related to error that Quicktime 5 (on OS X) exhibits:
'update existing software' is not able to run iff system volume is named '?'
(filled bullet) [option-8 on a UK keyboard, don't know about US]. Renaming the
volume enables it.


Fizzilla is more near and dear than future milestone... bringing it in the inner 
circle :-) and giving it some priority love...
Priority: -- → P3
Target Milestone: Future → mozilla0.9.3
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
bulk move to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Keywords: hang, nsBranch
Whiteboard: OSX+
darin, do you want to look at this.  I understand that you have a 0sX build.
Assignee: dougt → darin
I have an OS X build. Darin, do you want me to take this?
-> ccarlen (thanks... i only have a mach-o tree).
Assignee: darin → ccarlen
For this problem to happen, the name of the volume must *be* a bullet char
rather than *contain* a bullet char? If so -> 0.9.5. If just containing a bullet
char kills us, I'll give it higher priority.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Happens for volume names:
 €    [filled bullet]
h€r [h and r before and after filled bullet]
ærø [ISO8859 characters æ and ø]
and probably other similar ones.


does not happen for volume name:
hr
(and other US-ASCII presumably)
Alright, that's a more serious problem. Back to 0.9.4
Target Milestone: mozilla0.9.5 → mozilla0.9.4
If I rename the OS X boot volume to the bullet char [option-8], MozillaDebug
just exits before its icon does even one hop. No crash, nothing to the console.
I couldn't launch CW7 for debugging because it complains about a registration
key not being found and quits. So, I launched CW7, renamed the volume and
started mozilla in the debugger. On starting it, it crashes with an access fault
in CarbonCore before hitting main().

This is bizzare - Today's optimized NS6 build gets as far as putting up the
splash screen and immediately crashes. I should be able to collect a stack trace
from that and get somewhere.

I changed my volume name to have a bullet char (option-8) between 2 ASCII chars
It dies because opening the component registry fails because that code must be
passed a path. nsLocalFileMac::GetPath() is returning the wrong thing. The
problem goes down to the call to PBGetCatInfo in FullPath.c. When getting the
volume name, instead of "X?1", PBGetCatInfo returns "X#2" ??? I'll have to do
some research...
Instead of using FSpGetFullPath, which looks like it's not going to work under
OS X, we can use a series of calls to FSGetCatalogInfo. At least this returns
the name of each node as a unicode string. Unfortunately, this has to be mapped
back into the fs charset which GetPath() is supposed to return (argh)
The patch uses FSGetCatalogInfo under Carbon to build the path which works.
While the program now starts up, it still doesn't quite run because other code
is still referencing code in nsFileSpecMac which is a clone of FSpGetFullPath so
it doesn't work. Two options:
1. Get rid of this code (that which uses nsFileSpec -> nsFileURL)
2. If that's too much of a chore, gut the routine in nsFileSpecMac to make an
nsILocalFile and get the path from it.

Simon, Frank, can you review what's here so far?
Marking as PDT+. We'd like to take this one.
Whiteboard: OSX+ → OSX+, PDT+
Just noticed something:
There are 2 lines like this:
+    char stackBuffer[33];
The size of 33 got left there as I was testing the condition of running out of
buffer space. Ignore that '33'. I changed it to be much larger.
Status: NEW → ASSIGNED
Blocks: 99194
Giving it a nsbranch+ because it already has a PDT+
Keywords: nsbranch → nsbranch+
Attached patch updated patch (obsolete) — — Splinter Review 

        Attachment #48324 -
        Attachment is obsolete: true

        Attachment #48324 -
        Attachment is patch: false

    
    

    
  
The 1st patch did not work when the file for which the path was requested did
not exist. The newer patch fixes that. It also makes the routine used by
nsFileSpecMac (which doesn't work) delegate the task to a temp nsILocalFileMac.

Need reviews.

    
  
Blocks: 99488

    
    

    
  
Comments:
MacFileHelpers::PathNameFromFSSpec() changes--
I'm a little concerned about performance here. I suspect this is something that 
gets called a lot, and I worry that the new way is slower than the old way. Do we 
have any performance measurements here?

nsFSStringConversionMac:
I prefer 'gFoo' for globals, rather than 'mgFoo'. Alternatively, use 'sFoo' for 
"static".

Have you debugged through it to ensure that the ConvertFromTextToUnicode/
ConvertFromUnicodeToText loops perform correctly when they have to iterate more 
than once? That's a complex API, and hard to get right first time.

mgHasHFSPlusAPIs: same comment about global naming as above.


    
    

    
  
> I'm a little concerned about performance here

Yes. In microseconds, the new way is slower (about 2000 vs. 1000)
PathNameFromFSSpec gets called about 40 times when starting up and opening mail.
What I haven't measured is how much of that is in building the path vs. Unicode
-> FS conversion. When bug 94323 is landed, we will only ever be returning
Unicode so the conversion will go away.

On the other hand, as far as performance, not sure what else we can do.
PBGetCatInfo is returning the wrong thing for the name in this case.

> Have you debugged through it to ensure that the ConvertFromTextToUnicode

Yes. The looping works. True, they are complex APIs. If you know of anybody with
experience with these APIs, it would help.

I'll make the naming changes you suggest.

    
    

    
  
0.9.4 is out the door.
Target Milestone: mozilla0.9.4 → mozilla0.9.5

    
    

    
  
0.9.4 is out the door.

    
    

    
  
This is not on Tian Tian Must Fix list for this release, and is marked P3.
Propose we up the priority, or consider minusing it.

    
    

    
  
Should this be a P1 and on Tian Tian list?

    
    

    
  
Can we try the patch on the trunk and then decide if it's a nsbranch+ requirement

Keywords: nsbranch+ → nsbranch
Whiteboard: OSX+, PDT+ → [OSX], PDT+

    
    

    
  
Sounds like a good idea. What I'd like is for somebody to apply the patch and
try it on an Asian system first. I asked ftang about this. If anybody knows
anybody else who can do that, let me know.

    
    

    
  
> and then decide if it's a nsbranch+ requirement

The question is not whether it's a requirement but if the patch is ready to go
in. Not being able to launch on systems with non-ASCII chars in the path is
about as bad as it gets for large parts of the world.

    
    

    
  
I meant to type 'nsbranch+ candidate'.  Good point on the non-ASCII parts of the 
world so let's get some trunk testing going.  ftang is back in town (I saw him 
yesterday) so hopefully he can test for you soon or direct somebody else in his 
group to try it.


    
  
Keywords: nsbranch → nsbranch+

    
    

    
  
Comment on attachment 49143 [details] [diff] [review]
updated patch

have not be able to test on Asian system. the patch looks good.

        Attachment #49143 -
        Flags: review+

    
    

    
  
After testing on a system set for Japanese UI and script, I had to make a small
change:

Instead of:
+        UnicodeMapping mapping = { kTextEncodingUnicodeDefault,
kTextEncodingMacHFS, kUnicodeUseLatestMapping };
+        err = ::CreateUnicodeToTextInfo(&mapping, &mgEncoderInfo);

I had to use this:
+
err = ::UpgradeScriptInfoToTextEncoding(smSystemScript, kTextLanguageDontCare,
+
	kTextRegionDontCare, NULL, &theEncoding);

and then
::CreateUnicodeToTextInfoByEncoding
using that encoding.

Simon, I changed the prefix on class statics from "mg" to "s" Can I get sr= on it?

        Attachment #49143 -
        Attachment is obsolete: true

    
    

    
  
sr=sfraser

Whiteboard: [OSX], PDT+ → [OSX], PDT+, ETA 09/28

    
    

    
  
qa to me, triaging "file" component... 

is this really related to file or some component (xpcom, strings)?
QA Contact: tever → benc

    
    

    
  
Checked into trunk. As soon as I hear results from IQA (and assuming they're
good), will check into branch.
Whiteboard: [OSX], PDT+, ETA 09/28 → [OSX], PDT+, FIXED IN TRUNK, BRANCH ETA 09/28

    
    

    
  
Can still repro this bug with trunk build 2001092721 on JA MacOS X (Version
10.0.4, build 4Q12)

1. most of high ACSII chars still have the same problem.
2. some JA double-byte signal chars, like '?' (sjis), have the problem.

    
    

    
  
Rui, do you have a build from today? It was checked in it Sep 28 02:19.

    
    

    
  
The latest build under ftp://.../10.x/ppc/2001-09-27-20-trunk/ is:

Netscape6-macosX.sit.bin    13476 Kb    Fri Sep 28 00:02:00 2001 Binary 
Executable

Not sure whether it is including your fixes or not.

    
    

    
  
talk to build team, they said they only do MacOS X build every 8PM. Untill 8PM 
tonight, we cannot verify that.

    
    

    
  
Can still repro this bug with trunk build 2001093021 on JA MacOS X (Version
10.0.4, build 4Q12)

    
    

    
  
Rui, it sounds like this had no effect on a Japanese system. That may be another
problem. Can you verify this bug as originally reported: non-ASCII chars on a
U.S. or Euro system.

If the name of the drive (the one for mozilla & system) contained a bullet char
[option-8] it would crash on launch. If we can verify that is fixed, this will
have done some good, as long as we are no worse off on a Japanese system.

    
    

    
  
Sorry, I could not find an US MacOS X. Can someone help with it?

    
    

    
  
For your reference:

Changed my system Language/Locale setting from Japanese/Japan to US English/US, 
tested with trunk build 2001093021 on MacOS X (Version 10.0.4, build 4Q12, the 
same version with JA), the results are:

1. Using problematic high-ASCII chars cannot repro this bug.
2. Using JA double-byte chars can repro this bug.

    
    

    
  
> 1. Using problematic high-ASCII chars cannot repro this bug.
That's good.

> 2. Using JA double-byte chars can repro this bug.
How can I know I'm using double-byte chars when I have my system set to
Japanese/Japan? Can you mail me some strings which I can copy & paste? When I
tested, not knowing the language, I just typed randomly :-/ 

    
    

    
  
Please find a JA test chars file attached (JA test chars.rtf), hope it helps.

    
    

    
  


  

    
    

    
  
After some testing with file names in attachment 51733 [details], this can't be solved
easily. On Mac HFS+, file names are all stored as Unicode internally. Using the
new ::FSGetCatalogInfo routine on OSX, it does return the correct Unicode file
name (verified). Since nsIFile::GetPath() has to return a char* string, it needs
to be converted from Unicode into what we consider the FS charset. On the Mac,
each component of a file path can have a different encoding when not represented
as Unicode and there doesn't appear to way to find out the non-Unicode encoding
of those components.

In short, this problem can't really be solved until nsLocalFileMac uses HFS+
when available (on systems >= OS 9) and all path accessors on nsIFile are
Unicode-only.
 

    
    

    
  
Did this ever make it on the branch?

    
    

    
  
> Did this ever make it on the branch?

No, because I couldn't conclude that the fix on the trunk worked based on:
> 1. Using problematic high-ASCII chars cannot repro this bug.
> 2. Using JA double-byte chars can repro this bug.

(1) confirms the the fix worked for the problem reported here but (2) is what
worries me.

Rui, can you confirm that (2) is no worse than before this was checked into the
trunk? If so, I'll check it in.


    
    

    
  
Verified with 2001-10-10 trunk.

1. On US language/locale, can still repro with JA double-byte chars.
2. On JA language/locale, can still repro with some JA double-byte chars and 
high ACSII chars.

    
    

    
  
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6

    
    

    
  
So, this is an open problem for the 094 branch and trunk?
Whiteboard: [OSX], PDT+, FIXED IN TRUNK, BRANCH ETA 09/28 → [OSX], PDT+, FIXED IN TRUNK, [BRANCH ETA 09/28]

    
    

    
  
Teruko or Ruixu, is this bug still needed for the branch?   It looks like from
Ruixu's comments that the bug is not fixed on the trunk even with this patch.
QA Contact: benc → ruixu

    
    

    
  
Rui, please answer Lisa's question.

    
    

    
  
Yes, this bug is not fixed completely on the trunk even with current patch.

    
    

    
  
If, by not completely fixed, you mean these cases,

1. On US language/locale, can still repro with JA double-byte chars.
2. On JA language/locale, can still repro with some JA double-byte chars and 
high ACSII chars.

those are different than the original bug report and what the patch intended to
fix. What I'd like verified is this:
(1) the bug as reported (non-ASCII single-byte chars on a US system) 
(2) with the patch that's now in the trunk, that the other problems you found
are not any worse on Japanese systems than before the patch.


    
    

    
  
As per Conrad's comments, should we separate i18n issue to a new bug?

    
    

    
  
Making this a dup of bug 96481. As I commented on 2001-10-04 08:41, this really
cannot be fixed until we are using Unicode file system routines available on OS
9.1 and X (bug 95481) and the nsIFile API is Unicode-only.

*** This bug has been marked as a duplicate of 95481 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE

    
    

    
  
Verified.
Status: RESOLVED → VERIFIED
Blocks: 75599
No longer blocks: 99488

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: