This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I recently experienced the benefit that HTML5 RegisterProtocolHandler seems to afford users by making use of the "ExportTabs" utility offered to browser-users employing Chrome as their web-tool of choice - and while elated- was equally taken back by the potential drawback that is HTML5/RegisterProtocolHandler/GMail/mailto's inability to parse/handle my POST request to construct an email. I would like to see future spec(s) embrace or enhance this feature-request so as to avoid a cap on the message-body length as is currently being posed by mailto: transforming requests via (I presume) HTTP GET query transformation. IOW, if the ExportTabs browser-extension works in conjunction with the RegisterProtocolHandler() implementation via taking the browser-user's open tabs and converting them (to include various html attributes) to a "mailto:user?body=<http GET request>",then a "mailto:user?body=<POST request>" capability would resolve my concern. I have not contacted the developer as to how their extension works, nor have I TBH conducted suitable research, but to those concerned, your great and attention to this work is indeed very appreciated!! Thank you for your commitment to open web'ed-ness.
I have reached the developer of the ExportTabs extension in hopes of determining why and/or how Google("Chrome") responds to mailto: when the registeredProtocolHandler for such a request is 'handled' by gmail. According to a post here (http://ow.ly/ldhhs), browser-vendors are apparently free to design paramenter-agnostic handlers such as is the case for handling mailto: requests,anyway.. Without having a more finely detailed specification/contract (perhaps awaiting browser-vendor agreement/discussion on the matter) for how to implement an enhanced mailto: protocol, it seems unlikely that the goal of using HTTP POST as an HTTP request method could be achieved. In other words, I am not aware of any enhanced-contract that binds mailto: protocols to be able to accept parameters or obliges browser-vendors to enable such a request, at this time.
Mozilla also explains in a way that rules out the possibility, succinctly, here: http://ow.ly/ldknJ
Raising priority and noting as requiring a minor "feature tweak" to an existing feature.
HTML5.1 Bugzilla Bug Triage: Incubation needed While it is a small tweak (e.g., to allow parameterized data to be passed (or accepted) by protocol handlers, including whether to use GET or POST, I can't help but think that some other mechanism may solve this use case better. My opinions aside, we'd want to incubate additional changes to these APIs [that are already not universally shipped in browsers (see https://github.com/w3c/html/issues/233). This bug constitutes a request for a new feature of HTML. The current guidelines [1], rather than track such requests as bugs or issues, please create a proposal outlining the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG [2]. As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process [3]. [1] https://github.com/w3c/html#contributing-to-this-repository [2] https://www.w3.org/community/wicg/ [3] https://wicg.github.io/admin/intent-to-migrate.html