Closed Bug 1395821 Opened 2 years ago Closed 2 years ago

entered URLs can be removed from the location bar, lost forever


(Firefox :: Address Bar, defect, P3)




Tracking Status
firefox57 --- wontfix


(Reporter: dietrich, Unassigned)


(Whiteboard: [fxsearch])

57.0a1 (2017-08-31) (64-bit) Mac OS X

I've seen this for quite some time.

Sometimes the location bar can be cleared when there's some kind of network issue.

This happens in a way that the URL is lost forever, which is pretty bad.

Unfortunately, I don't have exact STR.


1. Open a URL in a new tab

2. Encounter some kind of network failure, or switch networks, or something?

Expected: The URL is still in the location bar

Actual: The URL bar is empty

The contents of the URL bar should *never* be removed like this.
I believe this is probably bug 1163981.
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1163981
This is different - this is about the safety of user-entered data in the UI, regardless of whatever network hijinks caused the initial problem.

AI titled the bug in the way that I did because the solution must ensure the safety of user-entered data on the location bar.

It could be that fixing bug 1163961 might fix this bug... temporarily. But instead of relying on that bug to be fixed in a one-off manner, let's fix the front-end either way.
Resolution: DUPLICATE → ---
I've been on a dodgy network in India for a month, and this bug is driving me insane.

There are multiple ways in which a URL can begin to be loaded and then somehow (request doesn't complete or whatever) the end result is that the tab goes back to a "new tab" state.

This seems like a design flaw, where user data is created and lost without any recovery option.

Mr. Horlander, who's the right person to evaluate this from a design perspective?

Bug 1163981 is about one potential cause.

This bug is about ensuring that, whatever the cause, a URL that begins to be loaded in tab will *never* be removed from the tab until a next task begins (subsequent navigation, tab closure, etc).
Flags: needinfo?(shorlander)
Summary: entered URLs can be removed → entered URLs can be removed from the location bar, lost forever
There are a couple code points that I suspect may be involved:

when you're on a network where you can reproduce this, it may be nice to see of one of these is hit.
Flags: needinfo?(dietrich)
I don't think we need UX yet, we should first understand if the behavior is due to a code defect.
Flags: needinfo?(shorlander)
Whiteboard: [fxsearch]
I don't even have a build environment, so I can't look at those any time soon. The team of designers and engineers who work on this area should look at it.

Yes, this may be *any number* of code defects... but we already *have* the URL... I can see it when loading.

Which means we need to *design and code defensively* to protect user data.

That is why I have made very sure to keep coming back to this point in reporting this issue.

Experience has taught me that a one-off fix for underlying problem A will be landed and the bug closed, and then current or future problems B, C and D will undo that fix.

The fix to this bug should be that no underlying code defect, now or in the future, that can cause us to lose the URL.

We experienced this for many years in session restore and eventually learned the lesson: We cannot sacrifice users on the altar of our engineering failings (aka, all the bugs that we don't know about yet).
Flags: needinfo?(dietrich)
The problem is that this area of the code is in relation with various spoofing cases reported in the past, and I'm sure both of those call points have some relation with previous spoofing fixes, so we can't just be protective and never clear the url. In this specific case it's important to understand which spoofing protection was excessively overzealous, or we could reintroduce a security flaw.
As a user, I don't know about any of that. I just see a page not loading, and then an empty URL bar.

If there's also supposed to be some security UI showing up telling me that this page might be spoofing, then that code might be broken also, because I'm not seeing any messages or UI saying my URL couldn't be loaded for that reason.
Found a dupe that Marco had filed some time ago, merging.
Closed: 2 years ago2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1347495
You need to log in before you can comment on or make changes to this bug.