Just briefly speaking with Standard8, it's clear that resultDomain is pretty much useless nowadays, it just always boils down to templateURI.host. I think we should just remove it at this point and figure out a better solution for the future. The original reason for that attribute is autofilling search engine domains, but that feature never made to release and is disabled. Teverse parsing is using StaticData, it's a different use case than autofill so it may not be the right solution for us. For tab-to-search I think we should analyze if my idea that the search url host must END WITH the autofilled origin works for the built in engines, not start with (like we do now). If we don't find problems with build in engines, it should be fine. Potentially if that becomes problematic for some engine, we could add a bool to the engine definition like "autofillwithsubdomain" or such.
Bug 1668939 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Just briefly speaking with Standard8, it's clear that resultDomain is pretty much useless nowadays, it just always boils down to templateURI.host. I think we should just remove it at this point and figure out a better solution for the future. The original reason for that attribute is autofilling search engine domains, but that feature never made to release and is disabled. Reverse parsing is using StaticData, it's a different use case than autofill so it may not be the right solution for us. For tab-to-search I think we should analyze if my idea that the search url host must END WITH the autofilled origin works for the built in engines, not start with (like we do now). If we don't find problems with build in engines, it should be fine. Potentially if that becomes problematic for some engine, we could add a bool to the engine definition like "autofillwithsubdomain" or such.
Just briefly speaking with Standard8, it's clear that resultDomain is pretty much useless nowadays, it just always boils down to templateURI.host. I think we should just remove it at this point and figure out a better solution for the future. The original reason for that attribute is autofilling search engine domains, but that feature never made to release and is disabled. Reverse parsing is using SearchStaticData, it's a different use case than autofill so it may not be the right solution for us. For tab-to-search I think we should analyze if my idea that the search url host must END WITH the autofilled origin works for the built in engines, not start with (like we do now). If we don't find problems with build in engines, it should be fine. Potentially if that becomes problematic for some engine, we could add a bool to the engine definition like "autofillwithsubdomain" or such.
Just briefly speaking with Standard8, it's clear that resultDomain is pretty much useless nowadays, it just always boils down to templateURI.host. I think we should just remove it at this point and figure out a better solution for the future. The original reason for that attribute is autofilling search engine domains, but that feature never made to release and is disabled. Reverse parsing is using SearchStaticData, it's a different use case than autofill so it may not be the right solution for this bug. For tab-to-search I think we should analyze if my idea that the search url host must END WITH the autofilled origin works for the built in engines, not start with (like we do now). If we don't find problems with build in engines, it should be fine. Potentially if that becomes problematic for some engine, we could add a bool to the engine definition like "autofillwithsubdomain" or such.
Just briefly speaking with Standard8, it's clear that resultDomain is pretty much useless nowadays, it just always boils down to templateURI.host. I think we should just remove it and figure out a better solution for the future. The original reason for that attribute is autofilling search engine domains, but that feature never made to release and is disabled. Reverse parsing is using SearchStaticData, it's a different use case than autofill so it may not be the right solution for this bug. For tab-to-search, I think we should analyze if my idea to match the end of the search url host with the autofilled origin (rather than the beginning) works for the built-in engines,. If we don't find problems with built-in engines, it should be fine. Potentially, if that becomes problematic for some engine, we could add a bool to the engine definition like "autofillwithsubdomain" or such.