(In reply to Polly McEldowney [:pollymce] from comment #13) > i think we would need to understand what is being asked for in a bit more detail, i am still a bit confused, sorry... just feel like i am missing a lot of context. Adding a bit more details here: (1) When a user just types `example.org` into the Fenix location bar and hits enter, the location-bar code fixes up that string to add the "http://" scheme, and asks Gecko to load the resulting URL `http://example.org`. (The user's input was schemeless (no `http` or `https`), and the location-bar code adds the "http" scheme automatically in order to make it a valid URL for Gecko to load.) (2) There's now a flag that you can pass (added in bug 1812192) that Fenix can use in this circumstance to tell Gecko that the user input was schemeless (i.e. that we added the `http` scheme automatically). (3) Fenix is **not currently passing that flag** (which is understandable because that flag was only recently added), but ideally it should. Hence this bug. (4) The benefit here is that connections will be secure-by-default more often, and will just-work-by-default more often too (in cases where a site happens to have a broken insecure-http configuration, like `rbi.org.in` (per this bug) and `nih.gov` (per bug 1868167) Let me know if that makes sense or if clarification would help on any part there. (Happy to chat over slack too if that's easier.) > probably the best way forward for this is to fill in an intake request. [instructions here](https://mozilla-hub.atlassian.net/wiki/spaces/Mobile/pages/886898834/Firefox+Android+Engineering+intake+process), but basically there is a jira ticket template to fill in which asks a few more questions - the aim being to shape the work and fully understand the requirements and drivers behind it, so we can plan it in appropriately. Do you actually want folks to use that intake form for relatively-small bugs? Clicking through it, it looks like it's for substantial projects and new-feature-work; whereas this bug here is likely pretty small/targeted. We likely just need to have someone who knows Fenix's location-bar code take a look at the Firefox-for-desktop patch https://hg.mozilla.org/mozilla-central/rev/cecb7eec7fa1 (from Bug 1812192) and make the equivalent changes to Fenix's location-bar code.
Bug 1901120 Comment 14 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Polly McEldowney [:pollymce] from comment #13) > i think we would need to understand what is being asked for in a bit more detail, i am still a bit confused, sorry... just feel like i am missing a lot of context. Adding a bit more details here: (1) When a user just types `example.org` into the Fenix location bar and hits enter, the location-bar code fixes up that string to add the "http://" scheme, and asks Gecko to load the resulting URL `http://example.org`. (The user's input was schemeless (no `http` or `https`), and the location-bar code adds the "http" scheme automatically in order to make it a valid URL for Gecko to load. It uses insecure "http" for historical reasons.) (2) There's now a flag that you can pass (added in bug 1812192) that Fenix can use in this circumstance to tell Gecko that the user input was schemeless (i.e. that we added the `http` scheme automatically). (3) Fenix is **not currently passing that flag** (which is understandable because that flag was only recently added), but ideally it should. Hence this bug. (4) The benefit here is that connections will be secure-by-default more often, and will just-work-by-default more often too (in cases where a site happens to have a broken insecure-http configuration, like `rbi.org.in` (per this bug) and `nih.gov` (per bug 1868167) Let me know if that makes sense or if clarification would help on any part there. (Happy to chat over slack too if that's easier.) > probably the best way forward for this is to fill in an intake request. [instructions here](https://mozilla-hub.atlassian.net/wiki/spaces/Mobile/pages/886898834/Firefox+Android+Engineering+intake+process), but basically there is a jira ticket template to fill in which asks a few more questions - the aim being to shape the work and fully understand the requirements and drivers behind it, so we can plan it in appropriately. Do you actually want folks to use that intake form for relatively-small bugs? Clicking through it, it looks like it's for substantial projects and new-feature-work; whereas this bug here is likely pretty small/targeted. We likely just need to have someone who knows Fenix's location-bar code take a look at the Firefox-for-desktop patch https://hg.mozilla.org/mozilla-central/rev/cecb7eec7fa1 (from Bug 1812192) and make the equivalent changes to Fenix's location-bar code.
(In reply to Polly McEldowney [:pollymce] from comment #13) > i think we would need to understand what is being asked for in a bit more detail, i am still a bit confused, sorry... just feel like i am missing a lot of context. Adding a bit more details here: (1) When a user just types `example.org` into the Fenix location bar and hits enter, the location-bar code fixes up that string to add the "http://" scheme, and asks Gecko to load the resulting URL `http://example.org`. (The user's input was schemeless (no `http` or `https`), and the location-bar code adds the "http" scheme automatically in order to make it a valid URL for Gecko to load. It uses insecure "http" for historical reasons.) (2) There's now a flag that you can pass (added in bug 1812192) that Fenix can use in this circumstance to tell Gecko that the user's actual input was schemeless (i.e. that the location-bar code added the `http` scheme automatically). (3) Fenix is **not currently passing that flag** (which is understandable because that flag was only ~recently added), but ideally it should pass that flag. Hence this bug. (4) The benefit here is that connections will be secure-by-default more often, and will just-work-by-default more often too (in cases where a site happens to have a broken insecure-http configuration, like `rbi.org.in` (per this bug) and `nih.gov` (per bug 1868167) Let me know if that makes sense or if clarification would help on any part there. (Happy to chat over slack too if that's easier.) > probably the best way forward for this is to fill in an intake request. [instructions here](https://mozilla-hub.atlassian.net/wiki/spaces/Mobile/pages/886898834/Firefox+Android+Engineering+intake+process), but basically there is a jira ticket template to fill in which asks a few more questions - the aim being to shape the work and fully understand the requirements and drivers behind it, so we can plan it in appropriately. Do you actually want folks to use that intake form for relatively-small bugs? Clicking through it, it looks like it's for substantial projects and new-feature-work; whereas this bug here is likely pretty small/targeted. We likely just need to have someone who knows Fenix's location-bar code take a look at the Firefox-for-desktop patch https://hg.mozilla.org/mozilla-central/rev/cecb7eec7fa1 (from Bug 1812192) and make the equivalent changes to Fenix's location-bar code.