Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Notify user agent of xforms "capabilities"

RESOLVED WONTFIX

Status

Core Graveyard
XForms
--
enhancement
RESOLVED WONTFIX
13 years ago
a year ago

People

(Reporter: Allan Beaufour, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
cite doronr:
> The right way to do this is by adding our string to the
> general.useragent.vendorComment preference.  For example, the activex
> plugin adds "ax" to it.  As xpis can't add preferences, xforms code
> probably has to check on startup if our string is included in the pref and
> possibly update it to the latest version, or append it to the preference.

I do not have a clue about how to do this... anybody want to look at it?
(Reporter)

Comment 1

13 years ago
The idea is to have something like "xforms/1.00", so a server-side processor can
detect whether the browser has support for XForms.

Updated

13 years ago
Assignee: allan → smaug

Comment 2

13 years ago
Extending the MozillaComment section of the UA string may be the only acceptable
change to the UA string.  See:
http://www.mozilla.org/build/revised-user-agent-strings.html
(NOTE: I'm not sure if this is the most up-to-date doc on mozilla UA strings.)

Of course, it would be nice to avoid expanding the UserAgent string.  I suppose
there is not a mime type that could be mentioned in the HTTP/1.1 Accept header :(

Does the w3c have any proposal to handle this problem?  If not, then perhaps the
w3c should be queried.
This really shouldn't go in the User-Agent header.  It belongs in the Accept header.

And yes, http://www.mozilla.org/build/revised-user-agent-strings.html is the
most current doc.

Comment 4

13 years ago
I spoke with TV Raman briefly about this, and he didn't know of any standardized
solution to this problem.  He suggested working with the other folks developing
XForms useragents to come up with a reasonable defacto standard.
It seems like we'd really like a way to advertise all of the XML namespaces that
we recognize, since as darin said, all XML documents will have the same MIME type.
Something like an "Accept-XMLNS" HTTP header would be useful.  (I had an IRC
discussion with darin about this.)

It should have the capability to advertise versions and profiles as well.  Any
specification of such a header should probably define such version/profile
strings for important preexisting specifications (XHTML, SVG, XForms), leaving
it to later specifications to fill in their own.
(Reporter)

Comment 7

13 years ago
(In reply to comment #6)
> Something like an "Accept-XMLNS" HTTP header would be useful.  (I had an IRC
> discussion with darin about this.)
> 
> It should have the capability to advertise versions and profiles as well.  Any
> specification of such a header should probably define such version/profile
> strings for important preexisting specifications (XHTML, SVG, XForms), leaving
> it to later specifications to fill in their own.

If by profiles, you mean something like "combination of xhtml/1.1 and
xforms/1.0", and has an idea on how to define them, I'm the happy dude :)

I suppose this will not make it to the beta, so if we could add a comment to the
user-agent string until it is done, it would make my camp happy.

Comment 8

13 years ago
Created attachment 172461 [details] [diff] [review]
Adds xforms/1.0 to UA string

With this one the UA string looks like this:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b; xforms/1.0) Gecko/20050122

IE + FormsPlayer (+ MathPlayer) seems to have pretty similar UA string:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; formsPlayer 1.1; MathPlayer
2.0)

Comment 9

13 years ago
the problem w/ adding things to the useragent is that people will expect them to
be there. imo it is better to get this right than do the wrong thing early and
pay for it forever.
Created attachment 172503 [details] [diff] [review]
alternate approach for adding to the ua string

Comment 11

13 years ago
vendorComment is not additive, so if any other extension tries to modify that
preference, then you will be "fighting" with it to see who gets to set the
vendorComment :-(

Comment 12

13 years ago
doh! i meant productComment... same thing applies to it.  maybe we should
support some sort of additive API for it.
I think this does not belong in the user-agent string.
So wouldn't it be better to expose an API for Gecko extensions to add to the
Accept: header, and use a made-up XForms MIME type?

It's hard to believe that there isn't a de-facto, if not de-jure, type for
XForms.  application/x-xforms?  I see Hixie using
application/x-xforms-actions+xml in
http://www.hixie.ch/specs/xbl/XBL2-source.html (which you may have to visit by
going to its parent dir, then clicking on XBL2-source.html -- or read the Google
cache, lol).

Anyway, the UA is not for content negotiation, and the Accept header is not for
negotiating every little standard, but XForms and SVG are big, new, and optional
enough to justify some Accept: header bloat.

/be

Comment 15

13 years ago
Well, there is the hasFeature method off of the DOMImplementation interface
(http://www.w3.org/TR/xforms/index-all.html#expr-hasfeature).  But again, that
would be more for a sniffer approach.  Plus, we haven't implemented that feature
in our XForms extension yet as that would be a core change to Mozilla in
nsGenericElement::InternalIsSupported -> 
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsGenericElement.cpp#1130

unless there is some way to extend the values provided here for extensions that
I don't know about.

Comment 16

13 years ago
if there isn't, then we need one.
(Reporter)

Comment 17

12 years ago
Here's the section in the CDF draft:
http://www.w3.org/2004/CDF/Group/specs/CDR/wp1/wicd.xml#media-type-argument

I've been told that the CDF group leans towards solution 3 or 4, which is:
application/cdf+xml  ; profile=[profile ID]
or
applications/xml ; profile=[profile ID]

Anybody have some thoughts/comments on this?

(I'm way too tired and jetlagged or anything right now :( )
Summary: Add xforms user-agent string → Notify user agent of xforms "capabilities"
(Reporter)

Comment 18

12 years ago
We could add "XForms/1.0" to the user agent string using this:
http://www.mozilla.org/build/revised-user-agent-strings.html#implementation

Comment 19

12 years ago
(In reply to comment #18)
> We could add "XForms/1.0" to the user agent string using this:
> http://www.mozilla.org/build/revised-user-agent-strings.html#implementation
> 

Do we want to take into consideration that we might not be the only XForms extension ever available for Mozilla?  We can also say, 'screw the other guy', too :=)
(In reply to comment #18)
The problem with this approach is that it doesn't specify which host language is supported for using XForms.  If the server sees "XForms/1.0" in the useragent string, does that mean that XForms is supported in XHTML?  What about SVG, or any other host language?  The server can assume, but it's not explicitly specified in the useragent string.  I think the only corrent way to do this is using the CDF spec (comment #17).  But I have no idea when that spec will be finished.
(Reporter)

Comment 21

12 years ago
(In reply to comment #20)
> (In reply to comment #18)
> The problem with this approach is that it doesn't specify which host language
> is supported for using XForms.  If the server sees "XForms/1.0" in the
> useragent string, does that mean that XForms is supported in XHTML?  What about
> SVG, or any other host language?  The server can assume, but it's not
> explicitly specified in the useragent string.  I think the only corrent way to
> do this is using the CDF spec (comment #17).  But I have no idea when that spec
> will be finished.
> 

I'm aware of CDF, I wrote that comment myself :) But 1) yes, when will it ever be finished, and 2) for 99% of the cases people want xforms+xhtml. I would still like the CDF approach, but there might be an advantage in adding the string still. And including the extension version makes it easy to dertermine what we support.
(Reporter)

Comment 22

12 years ago
(In reply to comment #19)
> (In reply to comment #18)
> > We could add "XForms/1.0" to the user agent string using this:
> > http://www.mozilla.org/build/revised-user-agent-strings.html#implementation
> > 
> 
> Do we want to take into consideration that we might not be the only XForms
> extension ever available for Mozilla?  We can also say, 'screw the other guy',
> too :=)

:) "MozillaXForms/0.3"
Comment on attachment 172503 [details] [diff] [review]
alternate approach for adding to the ua string

What you could do is:

#filter substitution

pref("general.useragent.extra.xforms", "XForms/@PACKAGE_VERSION@");

I tried to get it working before finding this patch and it couldn't figure out package_version.  Maybe someone else has better luck :)
(Reporter)

Updated

11 years ago
Severity: normal → enhancement
xforms is obsolete.
Assignee: bugs → nobody
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

a year ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.