Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 433295 - Make prio.h constants easier to access from JS
: Make prio.h constants easier to access from JS
Status: NEW
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: unspecified
: x86 Windows XP
: -- enhancement (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Nathan Froyd [:froydnj]
Depends on:
Blocks: 757351
  Show dependency treegraph
Reported: 2008-05-11 22:09 PDT by John J. Barton
Modified: 2013-10-24 01:50 PDT (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Possible candidates for constants that need to be made available to JavaScript. (3.16 KB, text/plain)
2013-10-23 22:44 PDT, ISHIKAWA, Chiaki
ishikawa: feedback? (johnjbarton)

Description John J. Barton 2008-05-11 22:09:00 PDT
If you read
you'll see a table including various obscure values like PR_RDONLY. These values are in a header file prio.h, not useful for Javascript. These value have to be used in all kinds of file operations. Because the constants are not available in interfaces, folks write code with octal constants, which looks cool and retro and all that, but is a big waste of time for people who come later to maintain or reuse the code.

Or people use the constants even if they are not defined, as for example, nsIZipWriter,, see the bottom example code.

Or people recode the constants over and over and over again, see for example
Did they copy them correctly? Just more lines of code to test.

The values seem to be
612 /* Open flags */
613 #define PR_RDONLY       0x01
614 #define PR_WRONLY       0x02
615 #define PR_RDWR         0x04
616 #define PR_CREATE_FILE  0x08
617 #define PR_APPEND       0x10
618 #define PR_TRUNCATE     0x20
619 #define PR_SYNC         0x40
620 #define PR_EXCL         0x80
Comment 1 :Gavin Sharp [email:] 2008-05-11 22:15:40 PDT
I'm not sure that nsIFile is the right place for them, since they're related to IO rather than attributes of a file. Perhaps they'd be better suited on one of the stream interfaces?
Comment 2 John J. Barton 2008-05-12 08:57:25 PDT
They could be replicated at the highest points in the type tree where they are used, including nsIFile.  
Comment 3 Pierre Réveillon 2010-10-01 06:52:58 PDT
Now octal literals are deprecated, this would be really helpful.
Comment 4 Pierre Réveillon 2010-10-01 06:55:27 PDT
(In reply to comment #3)
> Now octal literals are deprecated, this would be really helpful.

Sorry, I was talking about permissions and not flags, but this seems to be the same problem.
Comment 5 ISHIKAWA, Chiaki 2013-10-23 22:44:33 PDT
Created attachment 821474 [details]
Possible candidates for constants that need to be made available to JavaScript.

I am trying to handle I/O errors during the saving of an attachment of a message
in thunderbird.

I just realized that in the whole operation of thunderbird, saving an attachment to native file system is one of the few places (maybe only?)
in TB where the user (and TB) needs to deal with 
the native platform's file system directly, and handle the I/O error encountered during the operation gracefully and the nature of such error
needs to be propagated to the user for subsequent handling.
("Aha, I forgot to disable write-protection on the USB memory stick" is one example.)

In other operations, TB can deal with abstracted upper-level objects such as
e-mail message, e-mail folder, and remote mail servers that talk protocols defined by RFCs, etc. (Only messy GUI to show the message in intelligible manner to the user and to let user compose e-mail message are outside the scope of RFCs, and the saving of an attachment of operation is one of such activities.)

Anyway, in trying to handle the I/O errors and to show the error encountered in an information-preserving manner so that the user can take a proper action,
I was made aware that the basic I/O error codes and other information that are
available in C/C++ side of the source code are not available to JavaScript at all (!)

So I searched bugzilla and came to this article.

So my understanding of the discussion here is that
we should put something like in the attachment to a system-wide visible
file, correct?

What file should that be?

We have waited far too long for this to happen, haven't we?

Comment 6 ISHIKAWA, Chiaki 2013-10-24 01:50:39 PDT
Hmm, this type of requests have been very popular everywhere, I suppose.
I just found out
Bug 757351 - Sync uses deprecated octal literals
which discusses the following:

It seems there are duplicate efforts everywhere :-(
Oh well.

Perfect is the enemy of good. I think we better publicize a few such solutions and see
what would be better (not the perfect choice).

To be honest, I have no idea what is the right solution for
say, the use of such symbolic values in,
Bug 928725 - Use of octal number is deprecated (JavaScript/ECMAScript) and so do not used it in xpcshell-tests files. 


PS: whichever file that catches the best attention among the developers would be useful...

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