33.08 KB, image/png
18.15 KB, image/png
13.60 KB, text/xml
3.65 KB, text/css
It would be great to have WML support in mozilla (it would allow testing of WML pages without needing special hardware). Docs can be found at www.wapforum.org.
The docs at WAP Forum for the Wireless Markup Language Specification are at http://www.wapforum.org/what/technical.htm -- currently http://www1.wapforum.org/tech/terms.asp?doc=SPEC-WML-19991104.pdf Are there any HTML docs?
Summary: [RFE] WML support → [RFE] WML (Wireless Markup Language) support
AFAIK no :(
I doubt mozilla needs this, as there are no plans for a Cellphone conversion ;)
Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
Yes, this might be cool. Confirming. Assigning to firstname.lastname@example.org until someone steps up to impliment it
Assignee: asa → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
How about P5, Future? (/me doubts he can change this but tries anyway)
Priority: P3 → P5
Target Milestone: --- → Future
Since WML is an XML dialect, isn't it theoretically possible to write a stylesheet like html.css for it and use that to render such documents properly? I'm not sure this is really such a good idea, though. I don't think that you can really achieve the look and feel of WML-on-a-phone in a browser, and that implementing this will give designers false confidence as to the usability of their work. YMMW, however.
Opesa has WML support and uses both a stylesheet and special code AFAIK btw: removing RFE since Severity already shows that it's a Enhancement...:)
Summary: [RFE] WML (Wireless Markup Language) support → WML (Wireless Markup Language) support
Would be nice!
For those that have not yet seen WML here is an example: <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card title="Homepage of JMS"> <p>Hello World!</p> </card> </wml>
Note that the applicable MIME types and file formats for WAP support are: WML files should normally be served as: "text/vnd.wap.wml" The WAP image format is WBMP, this is normally served as: "image/vnd.wap.wbmp" Additional MIME types (but less usually used than the above and for more obscure files that may not be needed for basic WAP support) are: For .WMLC files: "application/vnd.wap.wmlc" For .WMLS files: "text/vnd.wap.wmlscript" For .WMLSC files: "application/vnd.wap.wmlscriptc"
*** Bug 175355 has been marked as a duplicate of this bug. ***
I tried it with that wml file: <?xml version="1.0" encoding="iso-8859-1"?> <?xml-stylesheet href="wml.xsl" type="text/xsl"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card title="Homepage of JMS"> <p>Hello World!</p> </card> </wml> I had to rename it to .xml to make it work. I got an error message that the file ....ontimer... was not found.
The problem was located in <meta http-equiv="Refresh"> tag in XSLT. Mozilla understands <meta> in XSLT as real meta instruction and attempts to redirect. This is a bug in Mozilla. Easy workaround is substituting <meta> by <xsl:element name="meta">. I have this done. Another comment: WML has a "cards" conception. Card may be internal screen (and user may navigate it by pressing a links, waiting a timeout etc.) and may has redirection to external pages. Opera emulates cards nearly exactly as in cellular phone, but I emulate internal cards as <div>'s divided by <hr />. I think this is better for reading on big screen :) and is simpler for XSLT. External redirection is being emulated via <meta http-equiv="Refresh"> tag.
Attachment #107367 - Attachment is obsolete: true
Fixed minor error in substring function at template for <card ontimer>. <card ontimer="#label"> must have no redirection.
Attachment #107453 - Attachment is obsolete: true
Is it possible to configure Mozilla to automatically use this stylesheet if it comes across files of type text/vnd.wap.wml? Inserting <?xml-stylesheet href="wml.xsl" type="text/xsl"?> is fine when you are creating your own WML but it is not very helpfull if you are browsing the wireless web... I guess it's not possible looking at bug 126841.
Attachment #107460 - Attachment is obsolete: true
Same as comment #18. substring(@ontimer,0,2)!='#' works fine, but substring(@ontimer,1,2)!='#' no.
Attachment #107751 - Attachment is obsolete: true
It is still necessary that mozilla recognizes the .wml extension and the mime-type!
Jens, this imho will not be a big problem ;) 2all: Can anybody add suggestion keyword?
More correct work with selects having multiple="true" parameter. Implemented recognition of variable name and, if multiple items are selected, adding it values with proper names.
Attachment #107752 - Attachment is obsolete: true
Attachment #107753 - Attachment is obsolete: true
1. Major: changes in <anchor> template for better WML forms emulation. a) <setvar>s nested in <go> are removed in XSL output from <form> and placed outside. b) Excluding content of <go> from submit button. 2. Polish: emulating title attribute of <card> not as a tooltip, but as a visible card caption.
Attachment #107754 - Attachment is obsolete: true
Thanks to discussion with Arunan Balasubramaniam, contributor of bug 182621 (btw, it's very close to be fixed) I venture to express my consideration about necessary further steps for this bug: 1. Make Mozilla aware about text/vnd.wap.wml and application/vnd.wap.wmlc MIME-types. 2. Adding WML mime-types into "Accept:" field in Mozilla HTTP request headers 3. Decompiling of WMLC files. Specification of encoding algorithm is available at http://www.w3.org/TR/wbxml/ 4. Putting my XSL, JS and CSS files in some directory of Mozilla installation. Maybe, ./res directory is appropriate. 5. Generating user output. I guess using transformToDocument isn't the best method. Simpler way might be following algorithm: a) Browser gets WML or gets and decompiles WMLC. b) Often WMLs contain useless line feeds before <?xml version="1.0"?> header. It should be removed. c) Browser adds string: <?xml-stylesheet href="resource:///res/wml.xsl" type="text/xsl"?> directly after <?xml?> header. d) Browser displays resultant XML in browser window. I'm not an expert in C++ coding, but I hope that work described above will be not so hard ;)
Fixed trivial syntax mistake at line 207. BTW, just now I have tested this XSLT on complicated pages comparing with Opera 6.05 and can say that my XSLT+JS send WML forms even more correctly than Opera. Opera doesn't handle iname and ivalue parameters in <select> and completelly misunderstands <select multiply="true">
Attachment #108346 - Attachment is obsolete: true
all.js has: pref("network.http.accept.default", "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1"); So the WML types can probably be added there for testing at least (not tried this myself yet). I know there have been a few bugs about shrinking this header so proposing a change will not be popular. Take a look at the discussions in: Bug 125682 - HTTP Accept Header should be dynamically generated Bug 170789 - HTTP Accept: header should be tailored to context of the request
Maybe, changes in Accept field aren't necessary. Opera doesn't point WAP mimetypes in Accept field but it can read WML pages inspite of this.
This is cool. Could you add some indenting to the .xsl file to make it more readable? Also, you should assign this bug to yourself.
Doron, I'm neither a reporter nor a privileged user of Bugzilla so I can't change "Assigned" field. You could help me to do this ;) Indented XSL I'll have written soon - I would combine this with implementing <do> tag.
How do you test this? Do I need to download something or a special build?
Assignee: nobody → manko
Alas still nowise. I test it by this way: launching Opera, navigating WAP sites, downloading WMLs in special directory on my local disk, manually adding <?xml-stylesheet?> string. Local directory is mapped at my local webserver which is set up to add "text/xml" HTTP header for *.wml files.
Added styles for navigation buttons
Attachment #108343 - Attachment is obsolete: true
Added: nsWMLresetForms function to implement reset button functionality. Fixed: nsWMLcheckForm function now works better with GET forms
Attachment #108342 - Attachment is obsolete: true
Added: full support of <do> tag (navigation buttons). Fixed: pretty-print look with indents.
Attachment #108352 - Attachment is obsolete: true
Fixed: incorrect support of refresh button.
Attachment #108492 - Attachment is obsolete: true
Now implemented full functionality of <do> tag, including accept, help, prev, reset, refresh, options and delete buttons. Reset now resets all form elements, refresh reloads page, etc. Buttons have a small pictograms at left side. Screenshot will be uploaded soon. Improved support of GET and POST forms. Hurray! :)
It seems to me this looks agreeably :) Compare with Opera ;)
if you want to get this in, you need reviews. no idea who is appropriate for that, though.
Christian, besides my files we need some C++ code, as described in comment 30.
At the instance of timeless I post a screenshot of Tinderbox from URL: http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey&wml=1 WML from this URL was be downloaded and prepared as described in comment 37. BTW, <?xml?> declaration in this WML was be omitted, it will be added by me manually.
Mozillazine independent status reports show a WML mozdev project: http://www.mozillazine.org/articles/article2778.html http://wmlbrowser.mozdev.org/ I have sent an email to the list with this bug URL.
I am updating the wmlbrowser project at mozdev to use these XSLT files instead of XBL.
If any new files were added to the tree, where would they go? I am guessing extensions/wml. If patches were made against existing files, should they be under build/compile flags such as --enable-wml and MOZ_WML?
I think importance of this bug is more than simple WML support. I guess that fixing this bug we can implement general mechanism to show in Mozilla any widespread XML document formats such as DocBook, OpenOffice.org etc. by using XSLT and transforming to XHTML. So, changing priority and adding helpwanted keyword. Maybe we need to open new bug for "Implement general module to show widespread XML document formats"? Any considerations and suggestions are welcome.
Priority: P5 → P3
It's a good idea to make this more general. We should collect some XML formats besides WML we want to cover. (How about cHTML?) It would be necessary to have a mime table which tells a) to display that mime type in browser rather than downloading it and b) associates a stylesheet with the mime type.
> It's a good idea to make this more general. It's not a good idea to make this particular bug more general as the policy is one issue per bug report, but you may want to make a list and search Bugzilla to see if there are any RFEs on the other XML formats/markups you suggest. You could then check if there was a meta bug for them all which had them as dependencies, and if not create it. Not trying to sound harsh, just pointing out The Bugzilla Way :)
Attachment #108493 - Attachment mime type: text/plain → text/xml
In light of the new Mozilla road map, I would suggest that this bug and bug 182621 (WBMP decoder) are closed as they will not be core parts of any Phoenix build and all the effort made already be consolidated in the "wmlbrowser" project at Mozdev as a Phoenix extension. This is only a suggestion as this isn't my bug and "wmlbrowser" isn't my project. Manko, Matthew, what do you think?
I can't agree. That is my thesises: 1. Mozilla/Phoenix will be not only HTML, but also XML browser. Importance of XML abilities will only rise for the future. Maybe this XSLT will be an additional package, but bug 194351 should be implemented in main trunk. See bug 194351 comment 7. 2. Bug 182621 is unrelated to new roadmap. This is only an issue about one of several image formats and I would see it in main trunk.
> Maybe this XSLT will be an additional package That's all I was proposing, 194351 seems a good idea to allow Moz to be a generic XML content viewer. > Bug 182621 is unrelated to new roadmap. The roadmap points out that Phoenix will support the majority needs and features for niches and power users will be left as extensions. I think that very few Moz users want to view WBMP images at present, so it seemed logical to just bundle that decoder with WML support rather than try to add it to the trunk. Other more popular decoders may be taken out (e.g. MNG, apparently used in the far east) so the chances of WBMP going in to the trunk look slim, which I think is understandable given it's minority appeal. This isn't some sort of troll :) I think WML support would be cool and would like to see (and help get) it done.
Severity: enhancement → trivial
I hate my mouse.
Severity: trivial → enhancement
Arunan, unfortunately image decoders AFAIK are a pieces of binary code which should be compiled jointly with all Mozilla code and cannot be added separately by XPI package.
We should have an impl of wml, even if it does end up as an extension (if we did it in XBL it would be easier :) It really shouldn't be on by default as a desktop user doesn't need wml - but what about embedded devices/etc? We do want to conquer those :)
Doron, if we have bug 194351 fixed we don't need XBL for WML. We can write (or even get from developers) an XSLT for any desired XML format. I guess this would be very common and powerful opportunity.
I still don't believe that xslt is the right way to do it.
Note: wmlbrowser is broke in Moz 1.4. For whomever might be out there looking for something cool to do with their saturday evening.
Thanks. Failure on Mozilla 1.4 is logged as http://mozdev.org/bugs/show_bug.cgi?id=4011. I will put proper bug reporting links onto wmlbrowser.mozdev.org so that issues can be reported directly.
Fixed: 1. XSL substring function uses 1 for first character; 2. Use <xsl:copy /> for coincident attributes in WML and XHTML tags. Added: Support of "accesskey" attribute in links and form elements.
Added: Support for acceskey attribute. It appears as highligted digit in circle before corresponding element.
Attachment #108490 - Attachment is obsolete: true
The above attachments are now incorporated into version 0.4.1 of the wmlbrowser XPI at http://wmlbrowser.mozdev.org/
*** Bug 269681 has been marked as a duplicate of this bug. ***
Moving to Core:XML...
Component: General → XML
Product: Mozilla Application Suite → Core
QA Contact: doronr → ashshbhatt
shouldn't this just be available as an extension? is anybody seriously using wml anymore? let's not bloat the code anymore
So should this be WONTFIXED?
In my opinion this should be WONTFIX and clearly stated that this is available as an extension for the users who want it.
Maybe MiniMo guys should be interested.
WML is the base for the WAP service which delivers internet content to the GSM mobile phone. This service is rapidly growing in europe.
I dont quite agree. Most moderns phones now comes with a browser than reads XHTML. WAP and WML is not the future.
(In reply to comment #74) > I dont quite agree. Most moderns phones now comes with a browser than reads > XHTML. WAP and WML is not the future. Certainely not the future, but the present indeed. I use it on a daily basis, and, as a developper, I would be really happy to get rid of Opera (taht renders WML like a charm...)
(In reply to comment #75) > (In reply to comment #74) > > I dont quite agree. Most moderns phones now comes with a browser than reads > > XHTML. WAP and WML is not the future. > > Certainely not the future, but the present indeed. > I use it on a daily basis, and, as a developper, I would be really happy to get > rid of Opera (taht renders WML like a charm...) which clearly explains why this should be WONTFIX
(In reply to comment #76) > (In reply to comment #75) > > (In reply to comment #74) > > > I dont quite agree. Most moderns phones now comes with a browser than reads > > > XHTML. WAP and WML is not the future. > > > > Certainely not the future, but the present indeed. > > I use it on a daily basis, and, as a developper, I would be really happy to get > > rid of Opera (taht renders WML like a charm...) > > which clearly explains why this should be WONTFIX > Well, I do not agree. Anyone can tell me when WML browsers will disappear ? I don't think they will before years and years. So WML is present and near future... And this bug should be fixed... I just hope we do not want tools for the future but for the present... I heard somewhere that in the future HTML will disappear...
There is no need for this functionality to be in the core browser, the vast majority of Firefox or suite users have no need for it. So it should continue to exist as an extension, IMO.
(In reply to comment #78) > There is no need for this functionality to be in the core browser, the vast > majority of Firefox or suite users have no need for it. So it should continue to > exist as an extension, IMO. Agree with this...
Maybe, but if bug 194351 will be fixed, we'll have a better way to write any extension. Many people take interest in Oasis ODF, DocBook, MS Office XML Open Format etc., and I guess bug 194351 is what all we need.
(In reply to comment #78) > There is no need for this functionality to be in the core browser, the vast > majority of Firefox or suite users have no need for it. So it should continue to > exist as an extension, IMO. I use the extension and I think it's pretty useful, but I'd rather see this functionality in the core browser. Many people already thanked me in fr.* newsgroups because I helped them discover it, I mean, if it was available as a built-in feature, I'm convinced much more people would use it. As a bundled extension (see Chatzilla with SeaMonkey , never understood why Firefox doesn't have it), or in the core, but it should be there. WML too old? Have a look at Bug 118438, which corrects the gopher support... Bleating the code? Given the size of the wmlbrowser extension (57 Kb with a few language packs), that seems managable to me, although my coding skills are non existant (all I do is some translations for extensions). "Minor" functions, added together, end up as a difference with competing browsers. The humble opinion of a simple end user is that this bug shouldn't be WONTFIXed.
WML sites are disappearing, the majority of them pass to XHTML Mobile Profile. But bug 194351 still is topical.
(In reply to Manko from comment #82) > WML sites are disappearing, the majority of them pass to XHTML Mobile > Profile. But bug 194351 still is topical. I don't think so, because there is still existing WML site, such as: http://wap.rusnews.cn/ Some PRC's internet portal also providing WML pages until today. This page have collected some PRC websites, some of them can be access via WML format: http://123.pctowap.com/
(In reply to Krasnaya Ploshchad from comment #83) > (In reply to Manko from comment #82) > > WML sites are disappearing, the majority of them pass to XHTML Mobile > > Profile. But bug 194351 still is topical. > > I don't think so, because there is still existing WML site, such as: > http://wap.rusnews.cn/ > > Some PRC's internet portal also providing WML pages until today. This page > have collected some PRC websites, some of them can be access via WML format: > http://123.pctowap.com/ You can also find them via this page: http://123.pctowap.com/wap/
I think it's safe to say that we wouldn't take a patch for this anymore.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.