@Reporter: We don't have permission to access the provided URL.Please find the screen shot of the issue.Could you please provide the accessible URL of the issue  and if possible,Please create new profile without extensions and apps.Re-check once and let us know the observations of the issue which would help us to triage the issue further.

Thanks in Advance.

Deleted: 736591.png 86.3 KB

	736591.png 86.3 KB View Download

domain.com is an example. I already tested with new session, it's same.
I found this after change port in my NAS move 5003 to 5103 (always https). Chrome not autofill it and not suggest login from the same hote.domain.
But in other webaccess, other hote in same domain, chrome suggest same domain user/password
screencast: https://youtu.be/99oCvYDvTKQ  (just to see, more record is only in local DNS)

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

cc'ing vabr@ who knows about password manager.

Thanks for the report.

Different port is a different security origin. Chrome does not fill across different origins in general.

Filling across different sub-domains on the same eTLD+1, scheme and port is a specific feature introduced for a specific use-case: mobile-specific sub-domains. There is still some potential security risk in offering to fill in case the eTLD+1 detection fails due to having out-of-date records (that's why Chrome does not auto-fill in that case), but that risk is minimal and the user benefit significant (lot of pages use mobile-specific sub-domains).

On the contrary, not many websites serve content on the same scheme but two different ports. I'm not a security expert, but I guess the risk there is not lower than in the above case of sub-domain. Since the risk is not lower and the benefit is lower, the resulting trade-off is worse than in the above case and therefore Chrome does not offer to fill across different ports.

For this reason I am closing this feature request as WontFix. I am also adding the security component in case somebody from the security team does want to weigh in.

After talking to battre@, I'm not sure WontFixing this is correct.

To get this feature implemented, two parts are needed:

(1) A security assessment whether treating different ports the same as different sub-domains is safe.

(2) Somebody to implement this and launch this.


For (1), I'll let the people owning the Security component to comment.

For (2), while the change is unlikely to be heavy on the code side, it would still take some amount of work to launch this (e.g., UI review for the different-port-hint). Given the low frequency of real-world cases when sites serve content over non-standard ports, this is unlikely to be on top of my team's list soon.

I'll mark this as Untriaged until we get a statement regarding (1) from security. If we get a go, let's move it to Available. If it sits Available without action for more than a year, though, I propose to archive it.

Need to move this to Available to get it out of triaging queue. However, if there is not a realistic chance to implement it by June 2018, I still propose to archive this.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

duplicate of Issue 887890

Thanks for the pointer!