46135 - (input-helper-apps) input helper applications for file upload form submission

Status: NEW

(Core :: DOM: Core & HTML, enhancement, P5)

Description

[James Salsman]

The form element <INPUT TYPE="file"> takes an optional attribute
ACCEPT="[MIME pattern list]" which, according to the W3C's HTML 4.0 
standard as interpreted by Tim Berners-Lee, should allow for the 
upload of input from any device (such as microphones, cameras, 
text editors, etc.) capable of producing the specified type.
For example: <INPUT TYPE="file" ACCEPT="audio/*"> for audio upload.

Currently such elements are rendered only with a [Browse...] 
button, but a patch has been written --
  http://www.pollmann.net/data/salsman_audio_extensions.patch
(now slightly out-of-date) -- to support an additional 
[Record...] button, which should launch an external helper 
application to record microphone input data into a file in 
preparation for upload upon submission of the form.

Now that helper output applications have been implemented on 
Mozilla -- see bugids:  10958, 13784, 38374; see also:  15320, 
33768 -- this request for helper input applications is being 
submitted.  I believe this must be done soon to prevent the 
possibility of incompatible helper application registry 
database formats.

I believe that the registry of helper applications should 
be expanded with at least one column with a bit to indicate 
which applications are input applications.  Those few 
applications which are both (e.g., your favorite editor 
could be both an input and an output helper for text/sgml) 
should be registered twice because the command line 
aguments might be different, for instance.

The major work needed is to take the MIME string in the 
ACCEPT attribute of <INPUT TYPE="file"> and match it with 
the helper input applications, and if match(es) are found, 
generate one or more [Record...] buttons (perhaps with 
other lables, perhaps from the helper application registry) 
as Eric's patch illustrates, such that those buttons will 
launch the associated helper applications and return the 
generated filename to the value of the file upload element 
for correct submission.

To test an implementation, visit:
  http://www.bovik.org/testform.html
Note that the form element --
  <input type="file" ... accept="audio">
-- is treated as a standard file upload.

That element should ideally contain a "Record..." button 
which would query the helper application registry to find 
INPUT applications (requiring at least one new column in 
the registry) matching the "audio/*" MIME type, launch 
them with a generated filename argument, the application 
would then save the specified file, and the form, upon 
submission, would upload the recorded file.

For complete background information, please see:
  http://www.bovik.org/devup
Twelve important supporters of this feature request are listed on 
that page.  Over 150 more people have also endorsed the proposal.

Netscape's Eric Pollmann has written a patch (now slightly 
out of date) which provides an additional 'Record...' 
button for microphone upload, but doesn't interface with 
the helper applicaions code because it didn't exist when 
Eric did the patch:
  http://www.pollmann.net/data/salsman_audio_extensions.patch
I spoke to Eric two days ago and he agreed it was time to 
open this request.  Thanks to him for the good work and advice!

Finally, please note that Tim Berners-Lee -- the Director of 
the W3C -- has made this specific request, because it is the 
proper behavior of HTML 4, along with other reasons:
  http://www.bovik.org/devup/tbl-devup.txt

Comment 1

[sairuh (rarely reading bugmail)]

confirming... james, i'll turn on the CanConfirm bit for you in bugzilla (weird,
i'd think you'd have it!).

Comment 2

[ekrock's old account (dead)]

For now, marking Future as this is way, way too late for an enhancement request 
to be accepted by Netscape for FCS--we passed the new feature cutoff 
deadline ages ago. Marking helpwanted. Would love it if a member of the mozilla 
community would take this work on; they can get check-in permission from 
brendan or waterson. Or, could Tim Berners Lee contribute a resource, perhaps by 
retasking someone temporarily from Amaya? We accept gratefully all offers of 
help and patches!

Comment 3

[James Salsman]

Thanks.  Since the output helper applications have only just been 
completed, it would be much easier to implement this now instead of 
waiting after changes may be made to nsExternalHelperAppService.  
It will be worth it, not only from the HTML standard compliance 
perspective, but also will establish an elegant symmetry for helper 
applications (output AND input, instead of only one-way), and there 
is no question the capability will by very useful, easing powerful 
applications that are presently much more difficult.

I will do what I can to help and encourage the development of the work 
remaining on this, but I need the help of those with the cross-platform 
resources that I do not have.  (But please don't count on help from 
W3C's Amaya team, because they do not yet support <INPUT type="file">.)

It is clear to me that <mscott> and <pollmann> are the most qualified 
to make this happen, and I hope they will work together on the project.  
I pledge to buy food for them on a regular basis if that will help.

To start, I have a question for mscott, regarding:

http://lxr.mozilla.org/seamonkey/ident?i=nsExternalHelperAppService

Please note in nsExternalHelperAppService.h that these RDF resource 
fields are defined:  Description, Value, FileExtensions, Path, SaveToDisk,
AlwaysAsk, HandleInternal, and PrettyName.  I would like to ask mscott 
whether he thinks it would be best to add a field (such as "InputService", 
representing a boolean value) to extend the database of that class, or by 
establishing a new parallel input helper application service.  Clearly, 
existing output helper routines -- such as nsExternalAppHandler -- would 
have to be tweaked to ignore input helper apps, but the advantage would 
be that the existing helper application setup infrastructure (i.e., the 
prefs panel) would be reusable with the simple addition of a set of radio 
buttons labeled "input" and "output" (the default), and whatever other 
fields are needed (such as the name of the associated form button.)  

To help answer that question, here is a short excerpt from 
Eric Pollmann's www.pollmann.net/data/salsman_audio_extensions.patch :

+#ifdef AUDIO_EXTENSIONS
+  // create record button
+  nsString accept;
+  mContent->GetAttribute(kNameSpaceID_None, nsHTMLAtoms::accept, accept);
+  if (kNotFound != accept.Find("audio/")){
+    nsIHTMLContent* record = nsnull;
+    if (NS_OK == NS_NewHTMLInputElement(&record, nodeInfo)) {
+      record->SetAttribute(kNameSpaceID_None, nsHTMLAtoms::type, 
NS_ConvertASCIItoUCS2("button"), PR_FALSE);
+      nsCOMPtr<nsIDOMHTMLInputElement> recordElement = 
do_QueryInterface(record);
+      recordElement->SetDisabled(nsFormFrame::GetDisabled(this));
+      
recordElement->SetName(NS_ConvertASCIItoUCS2("_moz_audio_extensions_record_butto
n"));
+
+      aChildList.AppendElement(record);

So, 'accept.Find("audio/")' is the primary part of what needs to be 
generalized and attached to the new nsExternalHelperAppService 
field(s) (or a new service like ExternalInputHelperAppService, e.g., 
as the case may be.)  Other fields that might be needed include the 
name of the button (i.e., "Record..." for "audio/*".)  

The MIME type match is interesting.  If I'm not mistaken, the output 
helper apps' MIME type matching occurs in nsExternalHelperAppService.cpp,
within nsExternalHelperAppService::GetMIMEInfoForMimeType.
But in that routine I can't figure out whether the matching is performed 
by GetResource or GetTarget, so I really need mscott's help.

The ideal situation would be that an input helper application could 
be established with the UI as providing a specific MIME type or a 
general (major) MIME type, and such that a helper input app providing 
a specific MIME type would match an input element requesting either 
that specific MIME type or its major type.  For example:

  <INPUT type="file" accept="audio/wav"> 
  would match "audio/wav" input applications first, then "audio/*" apps.

  <INPUT type="file" accept="audio/*"> (or accept="audio" or "audio/")
  would match any "audio[/...]" input helper applications

  <INPUT type="file" accept="*"> would match all the input helper apps.
  (And would show each button, following [Browse...], for each application, 
  if the button names were made part of the input app helper prefs panel.)

  <INPUT type="file" accept="image/jpg,image/gif"> would best match 
  apps for "image/jpg" and "image/jpeg" and "image/gif" etc.  This 
  illustrates some of the subleties of getting this matching right.

  <INPUT type="file" accept="text/x-newstuff;pB=vB;pA=vA"> should 
  match apps that provide "text/x-newstuff;pA=vA;pB=vB", but is that
  overkill?  (Perhaps it would be better to provide a means to 
  transmit the ACCEPT value directly to the helper input app on its 
  command line with a %s string substitution capbility, and simply 
  ignore any MIME parameter/values?)

Anyway, I look forward to some guidance from mscott, and I really 
hope he and pollmann will be able to accomplish this.

Comment 4

[ekrock's old account (dead)]

Hi James, thanks so much for your interest in helping. I'm sorry if I wasn't 
clear. My point is that all available Netscape engineering resources are already 
more than fully booked in delivering the already-committed functionality in the 
time left for the first release. pollmann and mscott, like all other Netscape 
engineers, have to focus on fixing critical crashers, performance, and bugs with 
existing committed standards support and can't be asked work on implementing new 
enhancements not approved by the PDT during their working hours. (This doesn't 
mean they can't answer questions, if they have the time and choose to, to enable 
interested non-Netscape contributors to do the work.)

If someone on the Internet is willing to take full responsibility for 
implementing, QAing, and checking in this functionality with approval from 
brendan or waterson without breaking the true, we'd love it. If no one is 
willing or able to do that work, then Netscape will evaluate this functionality 
as an enhancement request for possible inclusion in a future release. Mozilla's 
functionality will improve as fast as Netscape and mozilla.org contributors can 
manage. The more help mozilla.org contributors provide, the faster the project 
will progress!

Comment 5

[James Salsman]

question:  are there any MIME type string matching routines published anywhere?

Comment 6

[Scott MacGregor]

Hey James...sorry for the lag....I'm still digging out from the non beta2 email
I got over the last couple weeks.

To answer your questions:
 I would like to ask mscott whether he thinks it would be best to add a field
(such as "InputService", representing a boolean value) to extend the database of
that class....

Sure, it seems like a natural extension to extend our RDF data source to include
another input attribute.

James wrote:
The MIME type match is interesting.  If I'm not mistaken, the output
helper apps' MIME type matching occurs in nsExternalHelperAppService.cpp,
within nsExternalHelperAppService::GetMIMEInfoForMimeType.
But in that routine I can't figure out whether the matching is performed
by GetResource or GetTarget, so I really need mscott's help.

GetTarget looks for a node in the graph which has a resource node corresponding
to the content type we are looking up information for.

Comment 7

[James Salsman]

Thanks, Scott; I'm going to make a first try at a patch for this 
in the next week.  I've been concentrating on the MIME type matching 
that Apache's src/main/http_config.c does in ap_invoke_handler(), 
and I think I can use those tricks to make that part short.

So, the database mods are looking like the big part now, but I 
understand the basics of how the RDF database system works with 
URI's, and how the MIME types are being represented.

On the other hand, I don't yet have a very good idea of what 
needs to be done to add stuff to the UI preferences panel, but 
that is supposed to be the easy part and I'm sure I can figure 
it out when the rest is ready.  I'm just very glad that you 
don't have plans that would prevent extending the helper app DB 
structures.  I'll let you all know how it goes.

Comment 8

[James Salsman]

>... I understand the basics of how the RDF database system
> works with URI's, and how the MIME types are being represented.

Before I dive in to this, are there any general docs on working 
with nsIRDFDataSource?  In particular, how do I properly handle 
the likely case that an old RDF database might be used when 
looking for the new field(s)?  [Anyone?]

Also, Scott and/or Ben, could you please provide just maybe a 
line or so of documentation for each of these helper app fields:

Description -- ?
Value -- ?
FileExtensions -- what format(s) are allowed?
Path -- ?
SaveToDisk -- ?
AlwaysAsk -- ?
HandleInternal -- ?
PrettyName -- ?

It looks like GetTarget is subclassed often enough: 
http://lxr.mozilla.org/seamonkey/ident?i=GetTarget
-- (how) can I override it in nsExternalHelperAppService?

And is that okay with everyone, to override GetTarget 
(or I should I just use something else in GetMIMEInfoForMimeType?) 
so that it does wildcard matching like Apache's ap_invoke_handler()?

I wish I had an extra year or five C++ experience.

Comment 9

[James Salsman]

[Adding Mac and Linux platform bug dependencies for basic 
(output) helper application support which make this input 
helper enhancement more of a moving target than it will be 
when fixes for 50914 and 43585 are checked in.]

Comment 10

[Vladimir Ermakov]

Updating QA contact.

Comment 11

[James Salsman]

Marking dependent on the new upload corruption bug.

ekrock:  If this feature were implemented, you could perform regression testing 
for uploads and helper application launches in one step.  Plus with the respect 
you would gain by implementing it, perhaps you would attract better volunteer 
help, too.  I do hope that you will PLEASE reconsider supporting this 
officially.  Thank you.

Comment 12

[ekrock's old account (dead)]

James: no time, no resources to do new features before RTM. Netscape can 
evaluate the possibility of assigning resources to implement this for a future 
release. In the meantime, this is open source, so how about finding a volunteer 
to take this on? Or if TBL indeed wants this in Mozilla, how about asking 
him to reassign some engineering resources from Amaya (a non-commercial test 
bed) to Mozilla (free and open source, and the foundation for commercial 
browsers and appliances used by millions)? With more volunteers, we'll deliver a 
better open source browser product to deliver useful funtionality for the whole 
Internet.

Comment 13

[James Salsman]

ekrock:  Thanks for your suggestion:

> Or if TBL indeed wants this in Mozilla, how about asking 
> him to reassign some engineering resources from Amaya

There is no harm in asking.  Please draft a short request 
specifying exactly what kind of help you would accept for 
this project, and I will send it.

Sincerely,
James

Comment 14

[James Salsman]

ekrock:  My concern is that any additional volunteers would be as 
helpless as I find myself.

The only people who know what is needed to do this are pollmann 
and mscott, because the code is such a moving target.

But even if I can get volunteers from the W3C, more likely I can 
get them from other interested parties.  What I need to know is, 
how many hours of pollmann's and mscott's time will you pledge to 
assign to this for each hour of greenhorn volunteer time I can provide?

Alternativly, may I just pay Netscape/AOL in return for your 
agreement to assign Scott and Eric to this?

Cheers,
James

Comment 15

[ekrock's old account (dead)]

Hi James:
(1) This is open source, please go ahead and draft the request yourself, ask for 
the assignment of a C++ engineer and a QA engineer to work on this.
(2) I can't commit you a specific number of hours of specific engineers' time, 
nor is that necessary to be honest. When actual resources show up and reassign 
bugs to themselves, they generally find that they can get the information they 
need to make progress. If you get a C++ engineer and QA engineer and they find 
that they're blocked for lack of info, (1) post questions in newsgroups, 
and if that doesn't work, (2) contact mozilla.org staff and request help as 
part of their role is making sure that non-Netscape contributors are empowered 
to participate, and (3) escalate to me as necessary.
(3) Netscape/AOL don't currently fix specific bugs on a pay-for-fix basis. 
However, you could hire a contractor yourself if you wished from collab.net or 
someplace similar.

Comment 16

[James Salsman]

Testing reassignment.  I think it's very likely I can get 
engineers, but very unlikely that I can get people who 
understand what needs to be done more than I do.  But the 
problem is that my knowledge of what needs to be done is 
a sorry figment of what mscott and pollmann know.

My outstanding questions from my comment of 2000-08-16 14:18 
here will be posted to news:mozilla.ui soon.  I need to see 
what light the exthandler code (which Scott has pointed me to 
in bug 54940) will shine on the answers first, though.

ekrock: Would you have any objections to my offering to pay 
Eric and Scott directly to work on this during their off hours?
Would anyone else object that you know of?

Comment 17

[James Salsman]

Marking "correctness" because ACCEPT="mime-type(s)" is an explicit 
part of the official HTML 3.2, 4.0, 4.01, and one of the XHTML 
standards documents.  Also marking assigned.  Do I need to re-verify?

Comment 18

[ekrock's old account (dead)]

With respect to hiring Netscape engineers to work on their off-hours, I 
personally am all in favor of it if the particular engineers are interested, but 
it's not my call either way (whether they're interested in more work, and 
whether this is OK by company policy) -- you'll have to check with them 
individually about their individual circumstances. Since there's no conflict of 
interest whatsoever, I don't think this would be a problem, though, and in fact 
I'd raise hell with Legal if some bean counter started getting in the way on 
this. Go for it!

Comment 19

[James Salsman]

reversing the the false dependency on bug 44464, 
which should also be marked 'correctness' but is 
not as useful because (a) there are equivalent 
work-arounds at the HTML level with multiple file 
upload form fields, (b) practically nobody makes 
use of that because none of the legacy browsers 
implemented it, and (c) it isn't going to help 
people learn new languages like this one is.

Comment 20

[James Salsman]

Marking dependent on bug 54059: "unable to edit the 
MIME type textfield", for the same reasons as this 
depends on bug 57624: "editing mimeTypes.rdf from 
prefs hork the file", and cc:ing Matt.  This is the
last of what I can do this evening, for all of you 
who see this administriva -- thank you for your patience!

Comment 21

[timeless]

so far no comment from mpt.

Here is the layout i would accept:

( File       v |                         | [browse] )
( Microphone v | [Record] {[Stop] | [Play]} [Clear] )
In this format, things either are plugins or follow a specific feature set.
Hovering over play will give a tooltip explaining the mime type and the size.
[Clear] is a browser feature and means discard the current stream.
If mpt prefers i would accept {[Record]|[Clear]}
{a|b} means only one of the set would be shown. 
Here is a plugin version, each button is probably pictoral w/ hover hints.
( Mic-Plugin v | [Rec] [Stop] [Play] [Clear] |>=========<==| )
|>=========<==| is a trackbar >< indicate the selection that will be sent.  

v triggers a listbox which displays at least all input helpers, possibly a 
special one label none to allow the user to easily send nothing. Hover or 
status hints or a second column should display what mime types or output 
formats the helper supplies.

I'll let mpt split this off.

Comment 22

[Matthew T (active 1999-2002)]

I'm not commenting on this, firstly because the UI would depend on the 
particular MIME type (this isn't necessarily just sound or video we're dealing 
with here), and secondly because it probably wouldn't be in Mozilla's domain to 
specify the UI. This seems as though it would be handled by `input plugins' (or 
helper apps) which provided their own UI (where the kind of plugins Web 
browsers have now are `output plugins').

Comment 23

[James Salsman]

I would hope that the form button's label could be taken from a field in 
the (expanded) helper application mimeTypes.rdf database, or simply the 
name of the helper app(s) [more than one might be available for any given 
ACCEPT="type..." e.g. ACCEPT="audio/* image/*"] to launch to acquire the 
data to submit.

And "Browse..." (or whatever the filepicker ends up being called) should 
still be there, too, in case the operator wants to select pre-existing file(s).

So, I agree with "Record..." but not "Stop"/"Play"/"Clear" which should be 
made available instead in the input helper app which gets launched when the 
"Record..." button is clicked.  Okay?

Comment 24

[James Salsman]

Eric Krock:  Based on our discussion last summer, I think it is time for me to 
ask you to assign this as you see fit, please. My offer to pay $1000 upon 
completion stands. Please let me know what else needs to be done to bring about 
completion.

Thank you!

Comment 25

[James Salsman]

> From: [e-mail]
> Subject: Re: helper app preferences schedule?
> Date: Wed, 31 Jan 2001 05:04:28 -0800
> 
> [This is an automated response.] I am on sabbatical from 12/25/00 to 2/5/01 
> and will not be checking email or voicemail....
> 
> For other issues, including the standards and technologies I manage directly
> (such as HTML, CSS, XML, RDF, DOM, OJI, JavaScript, and the Mozilla Plug-in 
> API) please contact my manager, Michael LaGuardia, at [e-mail].

Michael:  Do mscott and pollmann have enough time to do this now?

Comment 26

[James Salsman]

Michael:  Do mscott and pollmann have enough time to do this now?

Comment 27

[James Salsman]

Eric,

Since multiple uploads are "fix in hand", and helper apps have been getting 
much better, what do you want to do with this one?

Times are tough; if you don't take me up on my offer soon, I may have to 
withdraw it until the next Democratic adminstration.

Cheers,
James

Comment 28

[Kevin McCluskey (gone)]

Bulk reassigning form bugs to Alex

Comment 29

[John Keiser (jkeiser)]

This bug doesn't precisely *depend* on bug 83749, but its implementation would
make this implementation easier and a lot more likely because there would be
MIME type looping code in the tree, in form controls, readily accessible.  Plus
that bug is easier than this one :)

Comment 30

[James Salsman]

Doesn't 30 votes at least warrent a P4?

Comment 31

[James Salsman]

Matching priority with that of blocked bug 97806.

Comment 32

[James Salsman]

Marking dependent on bug 18219 because there needs to be a way to add helper 
applications.  Marking dependent on bug 59619 because case-sensitivity in MIME 
type matching needs to be fixed first (see comments q.v.)  Marked dependent on 
meta tracking bug 78106 for helper applications and MIME issues.

Comment 33

[James Salsman]

Alex:  please unfuture this bug, there is plenty to be gained by it.

For example, the fix to bug 8589 would cause an open in an editor instead of 
just a viewer.

If you decide not to unfuture, please post justification in the comments.

Comment 34

[James Salsman]

Process excluded Alex ("Excluding: [e-mail]")

Taking.

Comment 35

[James Salsman]

Raising to top priority on general utility grounds.

Would anyone care to nominate a reasonable target milestone?

Comment 36

[James Salsman]

Okay, the guiding proposals are:

<input type="file" accept="text/plain"> opens an editor with a gensymed 
filename to a file that doesn't yet exist in a directory where files can be 
written

<input type="file" accept="audio/*,image text/html"> lets the user select from 
that list including e.g., photoshop, composer, etc.

<input type="file" accept="application/xml;xform=URL"> opens an Xforms app.  
There needs to be a way to let the semicolon-prefixed parameter guide selection 
if there is more than one application/xml handler.

If you have a moment, would you please help me out by looking through 
the output helper apps you have configured for mime types that you want 
to be able to upload, tell me what happens when they get run with a 
filename argument to a file that does not yet exist?  Thank you.

Comment 37

[James Salsman]

I'm going to see how much time I can devote to blockers.  In the mean time, anyone who 
might be interested in a charter membership in what history will see as perhaps the most 
important educational technology SIG over the next several decades, email me the name 
of the milestone you want to take this as.  In three weeks, I'll award the bug to the person 
who I think can do it the best. Upon completion, I'll nominate for the honorary charter 
membership.

Comment 38

[James Salsman]

Targeting 1.6a, which does not yet appear on the roadmap.  

Does anyone think 1.5a (June 25th) is more reasonable?
I think Boris could do this in half the time I could, even 
if I had 20 hours/week for it, whereas I probably only have
around 10 hours/week.  Plus I'm some days out from one of 
the platforms, too.

Comment 39

[James Salsman]

New job on the immediate horizon, punting.

Comment 40

[marky brown]

i learned a lot from this post thanks phil! (In reply to Scott MacGregor from comment #6)
> Hey James...sorry for the lag....I'm still digging out from the non beta2
> email
> I got over the last couple weeks.
> 
> To answer your questions:
>  I would like to ask mscott whether he thinks it would be best to add a field
> (such as "InputService", representing a boolean value) to extend the
> database of
> that class....
> http://www.loan-reviews.net 
> Sure, it seems like a natural extension to extend our RDF data source to
> include
> another input attribute.
> 
> James wrote:
> The MIME type match is interesting.  If I'm not mistaken, the output
> helper apps' MIME type matching occurs in nsExternalHelperAppService.cpp,
> within nsExternalHelperAppService::GetMIMEInfoForMimeType.
> But in that routine I can't figure out whether the matching is performed
> by GetResource or GetTarget, so I really need mscott's help.
> 
> GetTarget looks for a node in the graph which has a resource node
> corresponding
> to the content type we are looking up information for.

Comment 41

[marky brown]

thanks for this post! (In reply to James Salsman from comment #37)
> I'm going to see how much time I can devote to blockers.  In the mean time,
> anyone who 
> might be interested in a charter membership in what history will see as
> perhaps the most 
> important educational technology SIG over the next several decades, email me
> the name 
> of the milestone you want to take this as.  In three weeks, I'll award the
> bug to the person 
> who I think can do it the best. Upon completion, I'll nominate for the
> honorary charter 
> membership. http://www.bank-i-danmark.dk and http://finansielle-raadgivere.dk

(In reply to James Salsman from comment #39)
> New job on the immediate horizon, punting.

(In reply to John Keiser (jkeiser) from comment #29)
> This bug doesn't precisely *depend* on bug 83749, but its implementation
> would
> make this implementation easier and a lot more likely because there would be
> MIME type looping code in the tree, in form controls, readily accessible. 
> Plus
> that bug is easier than this one :)

Comment 42

[markus vermund]

(In reply to marky brown from comment #41)
> thanks for this post! (In reply to James Salsman from comment #37)
> > I'm going to see how much time I can devote to blockers.  In the mean time,
> > anyone who billigaste lånet http://www.billigalaan.se/billigaste-lan
> > might be interested in a charter membership in what history will see as
> > perhaps the most 
> > http://www.laan-365.dk  kreditkort http://www.kreditkort365.dk lån http://www.laanesider.dk
> > important educational technology SIG over the next several decades, email me
> > the name 
> > of the milestone you want to take this as.  In three weeks, I'll award the
> > bug to the person 
> > who I think can do it the best. Upon completion, I'll nominate for the
> > honorary charter lån og spar http://www.laanogsparpenge.dk
> > membership. http://www.bank-i-danmark.dk and http://finansielle-raadgivere.dk
> 
> (In reply to James Salsman from comment #39)
> > New job on the immediate horizon, punting.
> 
> (In reply to John Keiser (jkeiser) from comment #29)
> > This bug doesn't precisely *depend* on bug 83749, but its implementation
> > would
> > make this implementation easier and a lot more likely because there would be
> > MIME type looping code in the tree, in form controls, readily accessible. 
> > Plus
> > that bug is easier than this one :)

Comment 43

[Sylvestre Ledru [:Sylvestre]]

Decreasing the priority as no update for the last 2 years on this bug.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage 
about the priority meaning.