functionality of data: protocol for custom forms in keyword.URL when searching from awesomebar is gone

RESOLVED WONTFIX

Status

()

Firefox
Search
RESOLVED WONTFIX
5 years ago
5 years ago

People

(Reporter: Mardeg, Unassigned)

Tracking

({regression})

23 Branch
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

5 years ago
bug 738818 being fixed means only OpenSearch engine searches now happen from the address bar, and I have a feeling the format of these engines doesn't allow for non-domain URLs like data:text/html
An example is in the URL field. It's a POST to startpage with search results customised with the "prf" input. A matching search engine with the same preferences of results can of course be created (when bug 862401 is fixed), so such an edge case is likely WONTFIX.
I just filed this because I may not be the only one who lovingly customised keyword.URL this way.
(Reporter)

Updated

5 years ago
OS: Windows XP → All
Hardware: x86 → All
Version: Trunk → 23 Branch
(In reply to Mardeg from comment #0)
> bug 738818 being fixed means only OpenSearch engine searches now happen from
> the address bar, and I have a feeling the format of these engines doesn't
> allow for non-domain URLs like data:text/html

Indeed, this isn't currently supported.

> An example is in the URL field. It's a POST to startpage with search results
> customised with the "prf" input. A matching search engine with the same
> preferences of results can of course be created (when bug 862401 is fixed),
> so such an edge case is likely WONTFIX.

Indeed, this is WONTFIX, for the reasons you state!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
(Reporter)

Updated

5 years ago
Blocks: 864065
You need to log in before you can comment on or make changes to this bug.