754498 - Domain should not be highlighted in the address bar when the URL differs from the page

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, defect)

Description

[Matthew N. [:MattN]]

Attachment: Paypal.com after addressbar is changed to www.ebay.com

Once the user changes the URL in the address bar, we shouldn't continue showing the identity info of the document's domain or highlight the newly entered domain name until it is navigated to.

See the attached screenshot that shows https://www.paypal.com with the address bar changed to www.ebay.com.  The highlighting of the domain makes it seem like it's important even thought it's not yet relevant for the displayed document.

I encounter this when I paste a URL or make other changes the address bar but then change tabs without navigating.

Comment 2

[Matthew N. [:MattN]]

Bug 667586 didn't seem to cover the domain highlighting (colouring "ebay.com" darker than "www.") and so I'll change this bug into just that specific piece since I don't think the same implementation details apply.

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug

This patch checks for the exact URL match and also for the case where the trailing slash on a domain name is elided.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug v2

This patch just checks pageproxystate, which will keep it consistent with our other showing/hiding of elements based on pageproxystate such as the bookmark star.

Comment 5

[Matthew N. [:MattN]]

Comment on attachment 625282 [details] [diff] [review]
Patch for bug v2

Review of attachment 625282 [details] [diff] [review]:
-----------------------------------------------------------------

This doesn't handle the case where you modify the URL bar and then switch to another tab and then switch back.

It also doesn't seem like UpdatePageProxyState is called enough since it won't reformat the addressbar I manually revert the URL.  It would also be good if UpdatePageProxyState did some normalization like you had in your first patch.

Comment 6

[Frank Yan (:fryn)]

Comment on attachment 625282 [details] [diff] [review]
Patch for bug v2

Review of attachment 625282 [details] [diff] [review]:
-----------------------------------------------------------------

Matthew, I don't fully understand your comment, but I recommend this approach because we should be consistent with the bookmark star's behavior and also the identity block once we fix bug 667586. Try observing the bookmark star's behavior through the following steps:
1. Focus the url bar.
2. Delete the last character of the url bar's value.
3. Unfocus the url bar.
4. Refocus the url bar.
5. Add back in that last character by typing it manually.
6. Press escape to revert the url bar.

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for bug v3

Thanks for catching the issue with switching tabs. I've fixed it in this version.

Comment 8

[Dão Gottwald [:dao]]

(In reply to Matthew N. [:MattN] from comment #0)
> I encounter this when I paste a URL or make other changes the address bar
> but then change tabs without navigating.

This seems like an edge case. I'd rather optimize for the common case of autocompleting or pasting a value and hitting Enter. Formatting the value once the location changed makes sense on a technical level, but it's not obvious to me how this delay actually improves the UI.

Comment 9

[Frank Yan (:fryn)]

(In reply to Dão Gottwald [:dao] from comment #8)
> (In reply to Matthew N. [:MattN] from comment #0)
> > I encounter this when I paste a URL or make other changes the address bar
> > but then change tabs without navigating.
> 
> This seems like an edge case. I'd rather optimize for the common case of
> autocompleting or pasting a value and hitting Enter. Formatting the value
> once the location changed makes sense on a technical level, but it's not
> obvious to me how this delay actually improves the UI.

That's a good point. The cause is that we don't call onLocationChange immediately when the user presses Enter, because we don't repaint the content area immediately.

My tentative thinking is that we shouldn't take this fix unless we can avoid the delay that Dão described.

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

Then we should take version 2 of the patch and not worry about the tab switching scenario.

Comment 11

[Dão Gottwald [:dao]]

(In reply to Jared Wein [:jaws] from comment #10)
> Then we should take version 2 of the patch and not worry about the tab
> switching scenario.

That patch has the same downside.

Comment 12

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.