Show pending URL in location bar (and store for session restore) for tabs with no history, non-web-controlled about:blank loaded and a pending new URL

NEW
Unassigned

Status

()

Firefox
Location Bar
--
critical
7 years ago
2 months ago

People

(Reporter: ithinc, Unassigned)

Tracking

(Blocks: 3 bugs, {dataloss, reproducible})

Trunk
dataloss, reproducible
Points:
13
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 (.NET CLR 3.5.30729)

When clicking a link with target=_blank, Firefox opens a new blank tab first then loads url in the blank tab. This prevents determining whether the url has been opened in another tab. We'd better open new tab with the url directly.

Reproducible: Always
(Reporter)

Updated

7 years ago
Blocks: 565515
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Actually I think bug 514310 fixed this, but that patch was part of Firefox 3.6 already...
(Reporter)

Comment 5

7 years ago
Actually whether in Firefox 3.6 or in Firefox 4.0 betas, this problem still exists and can be easily reproduced, so I cannot understand why you marked it as fixed.

Updated

7 years ago
No longer blocks: 565515
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Looks like nsIBrowserDOMWindow::openURI is explicitly called with no URI to provide a blank page.
Component: Tabbed Browser → Document Navigation
Product: Firefox → Core
QA Contact: tabbed.browser → docshell

Updated

7 years ago
OS: Windows XP → All
Hardware: x86 → All

Comment 7

7 years ago
The only way to make this work is to change nsIBrowserDOMWindow to handle all possible loads (and also change windowwatcher, domwindow, etc to propagate all the necessary information).  Right now it can't, which is why the caller just tells it to load nothing and then does the load itself.

Further, note that some of the things involved in setting up the load correctly are not scriptable at the moment.

With all that said...  why do we care about this?

Comment 8

7 years ago
More precisely, whatever code you're working on already has to handle this script:

  var win = window.open();
  win.location.href = url;

right?
(In reply to comment #7)
> With all that said...  why do we care about this?

It's actually user-visible. Opening a target=_blank link displays about:blank in the location bar until the location changes. If you cancel the load soon enough, you're stuck with about:blank in the location bar.

Comment 10

7 years ago
I see.  Is there a reason we can't update the location bar when the load starts in the special case of initial loads?

Comment 11

7 years ago
Note, also, that there are possible spoofing issues here if the location bar is set before the load finishes... e.g. if I'm at http://evil.com and I open a window to load https://trusted.com and then I stop the load and DOM-append  my own stuff into the window, it'll show my content... what will the url bar show?
(In reply to comment #11)
> Note, also, that there are possible spoofing issues here if the location bar is
> set before the load finishes... e.g. if I'm at http://evil.com and I open a
> window to load https://trusted.com and then I stop the load and DOM-append  my
> own stuff into the window, it'll show my content... what will the url bar show?

It would likely show https://trusted.com if we'd spacial-case all initial loads. This wouldn't be a concern for target=_blank links, would it?
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (obsolete)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)

Comment 20

7 years ago
And just so we're clear on expectations, we're talking post-2.0 stuff here, right?
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
(In reply to comment #14)
> > This wouldn't be a concern for target=_blank links, would it?
> 
> Not for _blank, but for named target links it would.

Ok, so could we treat _blank as a special case?

(In reply to comment #20)
> And just so we're clear on expectations, we're talking post-2.0 stuff here,
> right?

ithinc is talking about potential extension fodder, as far as I can tell.

Comment 25

7 years ago
> Ok, so could we treat _blank as a special case?

Why?  Note, btw, that core code treats a target=_blank link identically to window.open() (in fact the former calls the latter).

> ithinc is talking about potential extension fodder, as far as I can tell.

I'm missing something, clearly.  This is a code bug in document navigation.  Any changes to this area of code on the core side will not be happening before 2.0.  Right?
(In reply to comment #25)
> > Ok, so could we treat _blank as a special case?
> 
> Why?

To handle that case more user-friendly (comment 9).

> I'm missing something, clearly.  This is a code bug in document navigation. 
> Any changes to this area of code on the core side will not be happening before
> 2.0.  Right?

The case mentioned in comment 9 certainly can wait.

Comment 27

7 years ago
> To handle that case more user-friendly (comment 9).

But why only for _blank?

Anyway, it sounds like we need some UI design around the spoofing issue, if nothing else.
(In reply to comment #27)
> > To handle that case more user-friendly (comment 9).
> 
> But why only for _blank?

Because there's no spoofing issue with _blank.

> Anyway, it sounds like we need some UI design around the spoofing issue, if
> nothing else.

Comment 29

7 years ago
> Because there's no spoofing issue with _blank.

There is when it's used in window.open.  And again, link clicks and window.open look the same by the time you get to the code talking to nsIBrowserDOMWindow.
(In reply to comment #29)
> > Because there's no spoofing issue with _blank.
> 
> There is when it's used in window.open.

I mean <a target="_blank"> specifically, which luckily is the common case too.

> And again, link clicks and window.open
> look the same by the time you get to the code talking to nsIBrowserDOMWindow.

I understand that there are certain architectural constraints, but theoretically the code could be shuffled around such that <a target="_blank"> links could be loaded directly.

Comment 31

7 years ago
I guess I don't see why the entire core link-opening architecture needs to be rejiggered around this desire to special-case one very particular kind of link....

If you really do want to special-case that stuff, it still seems to me like doing it in the window provider is the right thing.
If there's a particular place where it could be special-cased without changing the entire world around it, we should do it there.

Comment 33

7 years ago
nsContentTreeOwner::ProvideWindow
An example of when current Firefox behavior is very annoying (I personally have encountered exactly this one today):

we click on a Flash banner, then Firefox says:
"Firefox doesn't know how to open this address, because the protocol (hhttp) isn't associated with any program."

Banner is created with Flash, so we cannot copy link with context menu of browser, therefore we cannot determine what the link url is. It's evident that URL in the banner just has a typo (unnecessary additional character "h" at the beginning), so we would correct URL manually just by deleting this character. But instead we see completely useless and nonsensical "about:blank" URL.

In Opera (for example), we just deleting first unnecessary character from URL _displayed_ in location bar, and then pressing "Enter" key again, and going to the page we need. Firefox does NOT allow this at all. VERY annoying.

Hopefully this will be fixed as soon as possible. Thanks.

Comment 35

7 years ago
Comment 34 has nothing to do with this bug as filed.  The UI could easily set the url bar's text to the url that failed to load in that situation; this bug is about the precise steps that take place in the initial tab setup.
(In reply to comment #35)
Please see comment 9. This is the exact thing I talking about.

Comment 37

7 years ago
Comment 9 is just a UI bug; nothing prevents the UI from showing the new URI once the load fails.  Nothing to do with this bug as filed.
(In reply to comment #17)
> > Can you tell me why "switch to tab" feature is added in Firefox 4? 
> 
> It's useful.  But sometimes I really do want to load the same thing in multiple
> tabs (in which case the feature actually gets in the way, btw; I kept meaning
> to file a bug on this, and just filed bug 610720).

I didn't check to see if you were on the list, but we got a number of bugs open under bug 480350 aka switch-to-tab.
(In reply to comment #37)
> Comment 9 is just a UI bug; nothing prevents the UI from showing the new URI
> once the load fails.

OK. Is the bug 601540 a UI bug you are talking about? For clarity, I talking about this:

URL should be displayed in location bar _immediately_ after opening a link, without displaying about:blank at all, and _irrespectively_ of is URL correct or incorrect.
Created attachment 493573 [details] [diff] [review]
patch

ProvideWindow wasn't getting the URI, so I had to fix that first. Also, I figured it would make more sense for ProvideWindow than for OpenWindowJSInternal to stop the initial load.
Assignee: nobody → dao
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Updated

7 years ago
Created attachment 493584 [details] [diff] [review]
patch
Attachment #493573 - Attachment is obsolete: true
Attachment #493584 - Flags: review?(bzbarsky)

Comment 42

7 years ago
Comment on attachment 493584 [details] [diff] [review]
patch

No, this is wrong.  This will cause two loads for the url to start in the new window, no?
Attachment #493584 - Flags: review?(bzbarsky) → review-
I didn't see this as a problem, as the first load is stopped immediately.

Comment 44

7 years ago
It's definitely a problem from my pov, because it sends all sorts of spurious notifications (and incidentally, if the url is javascript: the load is NOT stopped immediately as far as I can tell, so it'll execute twice).
(In reply to comment #44)
> It's definitely a problem from my pov, because it sends all sorts of spurious
> notifications

Yeah, but it already does that for about:blank...

> (and incidentally, if the url is javascript: the load is NOT
> stopped immediately as far as I can tell, so it'll execute twice).

Ok.
Comment hidden (advocacy)

Comment 47

7 years ago
> Yeah, but it already does that for about:blank...

Yes, but about:blank won't trigger various security policies, won't make two possibly-nonidempotent requests to the server, won't run javascript: twice, and is generally much better behaved than your average url.

Just to be clear: a prerequisite for any solution to this bug is that the load of the actual url being opened start only once.  That means either not doing it from the UI or passing all the information needed to do the load to the UI.

Either one requires interface changes, as I said (e.g. for the former approach you could add a new "url we plan to open" argument to the call that would allow the UI to find the right tab to do the load in).
(In reply to comment #47)
> Either one requires interface changes, as I said (e.g. for the former approach
> you could add a new "url we plan to open" argument to the call ...

I thought comment 31 and comment 33 suggested fixing this without interface changes. I guess I misunderstood them.

> ... that would allow the UI to find the right tab to do the load in).

Not sure what exactly this means. It seems to be targeted at comment 13 et al, which I don't think we should care about.

Comment 49

7 years ago
> I thought comment 31 and comment 33 suggested fixing this without interface
> changes.

They're the place to fix without having to totally change how loading works; just pass more information to the provider.  But yes, it would need an interface change, sadly, since we don't pass the URI in right now.

> Not sure what exactly this means. It seems to be targeted at comment 13 et al,

Yes.

> which I don't think we should care about.

Then what _are_ we caring about, exactly?  Comment 13 was the one thing I found so far in this bug which seems like it needs backend changes...
Comment 13 seems to speculate about a future feature, or maybe ithinc wants to write an extension doing that. What I think we should primarily care about here is the current actual user experience. For target="_blank" links, we should display the target URL rather than about:blank until Firefox got a response.

Comment 51

7 years ago
Why does that need core changes?  That seems to be doable wholly in the front end, no?  I mean.. the front end knows that a load is happening, and what the URI of that load is!
I don't think front end code can do this specifically for target="_blank", as it doesn't know the window name, but maybe I'm missing something.

Comment 53

7 years ago
Oh, I see.

It's still weird to me to hack the target="_blank" case but not the window.open("...", "_blank") case or the target="foopy" case.  but yes, if you want to make such a distinction then we need core changes (at least in the window provider impl you changed; past that depends on whether we want to communicate the target to the UI or communicate the real url to the UI or both).
(In reply to comment #53)
> It's still weird to me to hack the target="_blank" case but not the
> window.open("...", "_blank") case or the target="foopy" case.  but yes, if you
> want to make such a distinction then we need core changes

It is my understanding that the distinction is needed to prevent spoofing.

Comment 55

7 years ago
Well, it's _one_ way of preventing spoofing, and imo a poor one: it leads to inconsistent behavior on link clicks that look identical to the user, depending on whether they do window.open or use the target on the <a>....

Comment 56

7 years ago
For example, perhaps the url bar should stay blank but the url that was trying to load should be the first suggestion in the awesomebar if the user actually clicks in the url bar.  That solves the spoofing issue, while allowing quick access to editing the url we tried to load.  This could be used in other cases too, like doing "open in new tab" on a link that leads to something that gets handled with a helper app...

There might be other approaches too.  Having a clear description of the problem(s) we're trying to solve would be helpful here, I think...
Sure, there might be ways to improve this for cases with the opener having access to the window. But whatever we do there, we're limited by the spoofing risk, which requires us to avoid the most user-friendly solution, i.e. just putting the URL in the location bar. That shouldn't prevent us from implementing that solution for the very common target="_blank" -- which, while inconsistent with target="foo"/JS links, would be consistent with ctrl+clicking a link.

Comment 58

7 years ago
> the very common target="_blank" 

Do we actually have frequency data?  I'd be interested....  I agree that if this is common enough it might be worth special-casing it.

Another option would be to show the url in all cases but drop it if the DOM then mutates...  That's hard to do right now without using mutation listeners, unfortunately.  But if we're going to change things around anyway, maybe it's better to address this instead or in addition?

Updated

7 years ago
Blocks: 601540
(In reply to comment #58)
> > the very common target="_blank" 
> 
> Do we actually have frequency data?  I'd be interested....  I agree that if
> this is common enough it might be worth special-casing it.

I don't have data. I have this code in my userContent.css:

a[target="_blank"]:hover {
  background: yellow !important;
  color: red !important;
}

It's used quite often in forums and cross references in news articles. Also iGoogle.

Updated

7 years ago
Assignee: dao → nobody
Status: ASSIGNED → NEW
Comment hidden (obsolete)
(In reply to comment #60)
> Suppose you edit a html file in an external editor and view it in Firefox,
> every view will open a new tab. The new tab is added with no knowledge of the
> url to be loaded.

We already load the URL directly in that case (bug 562649).

Updated

7 years ago
Duplicate of this bug: 619472

Updated

7 years ago
Duplicate of this bug: 569047

Comment 64

7 years ago
Bug 569047 has code that shows that this also disturbs code that tries to wait for the page to load.
Duplicate of this bug: 648279

Updated

6 years ago
Duplicate of this bug: 650631

Comment 67

6 years ago
Regarding the UI issue of losing the URI with indefinitely-loading pages or cancelled loads, comment 35 says that the problem isn't this specific bug. Which bug is it?

Updated

6 years ago
Duplicate of this bug: 616938

Updated

6 years ago
Duplicate of this bug: 661783
I see several problems here.

Currently the URL in the location bar is replaced only after the page data starts loading or an error is shown. Replacing it earlier would lead to content and URL not matching (which is easily achieved by editing the location bar and then switching tabs anyway).

For initial loads like window.open, opens from external app, opens in new tab, session restore, etc. there is no previous URL so the new tab/windows shows no URL until the page loads or times out.

This leads to multiple annoyances:

1) when the URL is wrong it is never shown
2) when the load fails without getting any error (probably connection is lost somewhere in the middle of loading headers) the tab shows an URL and no content, and reloading it gives a blank page.

Both of the above could be solved by special-casing the about:blank URL. When loading an URL on top of about:blank the URL should be immediately associated with the tab, not only after a successful load. This does not lead to spoofing because about:blank contains no content that could be mistakenly associated with the new URL.
Michal, you're on Firefox 3.6, things have changed since then.

Comment 72

6 years ago
Bug 440785 describes a couple of quirks with the timing of the address bar getting updated which do show up in Firefox 4 - it seems that the issues described here could, potentially, be of the same origin.
Yes, this is totally related. The tabs can be in a state transitioning from one URL to another, and that part is handled poorly by Firefox.

This state could be avoided for tabs transitioning from about:blank making the issue much less visible because then the tab will either have the old URL or the new URL but there will be no "without URL" state.
Comment hidden (advocacy)

Updated

6 years ago
Duplicate of this bug: 689597

Comment 76

6 years ago
Does anyone know the answer to comment 67? If I click a lot of window.open / target= links in an article and don't read them straight away, then switching to one later that is stuck indefinitely loading or has failed to load in some way which leaves the location bar empty is frustrating. It's a lot of effort to go back and try and find what that page was meant to be.

Both issues seem similar to me, but if one won't be fixed in this bug then I'd like to know which bug it will be fixed in.

It doesn't seem to be a problem when middle-clicking a link (see the URL field of this bug). Middle-click one of the links and then left-click on of the links. One shows the address that is loading and one does not.

Comment 77

6 years ago
The blank url bar issue is NOT this bug.  It's a pure UI issue.
(Reporter)

Comment 78

6 years ago
(In reply to Boris Zbarsky (:bz) from comment #77)
> The blank url bar issue is NOT this bug.  It's a pure UI issue.

Not really. If it's a window.open, it will be too difficult for the UI part to get the correct URI. For example:

onclick="openUrl();"

function openUrl() {
  window.open(...);
}

Comment 79

6 years ago
> If it's a window.open, it will be too difficult for the UI part to get the correct URI.

How so?  The UI part can know the url as soon as we start the HTTP request.  We report it to the UI and all.
(Reporter)

Comment 80

6 years ago
(In reply to Boris Zbarsky (:bz) from comment #79)
> The UI part can know the url as soon as we start the HTTP request. 
> We report it to the UI and all.

I don't think the UI part can know the url before the onLocationChange, unless you mean the observer notification "http-on-modify-request"?
The UI part only sets a loaded URL or the initial URL of a tab in the url bar. For example, if you click a link, which will be opened in the current tab, the url bar won't change immediately. This just behaves the same as a new tab.

Comment 81

6 years ago
I mean the onStateChange notification we send with the "hey, starting a new document load here now" flags.
Depends on: 891452
No longer depends on: 891452

Updated

4 years ago
Duplicate of this bug: 921970
Comment hidden (advocacy)

Comment 84

4 years ago
Actually, the original version of this bug is 9 years old. https://bugzilla.mozilla.org/show_bug.cgi?id=254714
I reported it on Firefox 0.9. 
It was fixed, but later reappeared.
Comment hidden (advocacy)
Patches for the bug are certainly welcome.

Bug 878747 may have made this easier to fix.
Comment hidden (advocacy)

Comment 88

4 years ago
easy repro if i use 2 addons with getBrowser() function
Comment hidden (advocacy)
Adding to the Triage Tracker for the Triage Team to review and consider for the Product Backlog.
Blocks: 981530
Flags: needinfo?(mmucci)

Updated

3 years ago
Flags: firefox-backlog?

Updated

3 years ago
No longer blocks: 981530

Updated

3 years ago
Flags: firefox-backlog? → firefox-backlog+

Updated

3 years ago
Whiteboard: p=13

Comment 91

3 years ago
(In reply to Boris Zbarsky [:bz] from comment #7)
> With all that said...  why do we care about this?

This bug haunts bad connection users everyday... Please make some effort to fix this. It's more than preventing implements of Tab extension features.

Let say one opens a link with _blank, when the response is choked, he will have no way to determine what those tabs URL are, and if you can't stop loading and reload it too, because there is no URL in locationbar to reload! One has to wait tens of second until firefox finally receive server response or prompt Page Request Timeout.

If, unfortunately, the browser crashes when loading, you'll restart the browser with blank page, no history left either....  And this is the way for many years..... really annoying... I understand the pain, because I am one of those users with terrible internet connection.

Updated

3 years ago
Points: --- → 13
Flags: qe-verify?
Whiteboard: p=13

Comment 92

2 years ago
Sorry, but as I said last year, and 2011, this bug is a torture for bad connection, and it happen.. Just curious why qe-verify postpone for a years?

Updated

2 years ago
See Also: → bug 798249

Updated

2 years ago
Blocks: 1172949

Updated

2 years ago
Blocks: 1054740

Updated

2 years ago
Duplicate of this bug: 858448
Duplicate of this bug: 1022233

Updated

2 years ago
No longer blocks: 1054740

Comment 95

2 years ago
Dear Mozilla,
I initially reported this behavior in 2004 (bug 254714) on Firefox v0.9 (Firefox has been my default browser when it was still called Firebird). After a few years it was fixed for a while, and then started again (hence this bug was opened).
Both the original bug and this one have many duplicates: 211856 261453 263497 268112 268856 269870 270330 272786 272844 280455 286320 286335 288934 291863 295064 295441 302587 302923 361156 374664 456731 464434 491582 569047 616938 619472 648279 650631 661783 689597 858448 1022233.

Please, please, please fix it.

Comment 96

2 years ago
BTW, among all the attempts to reproduce, this is the simplest one (which I reported on 2011 -- bug 254714 comment 101).


1. Go to http://twitter.com/firefox. 
2. Click the link to mozilla.org.

On a good connection, the new tab will briefly have "about:blank" in the address bar. On a bad connection, it will stay that way. This happens a lot on the train: sometimes the signal vanishes for ~30 seconds, in which case I lose the URL.

Comment 97

2 years ago
(In reply to Noam Tamim from comment #96)
> BTW, among all the attempts to reproduce, this is the simplest one (which I
> reported on 2011 -- bug 254714 comment 101).

The most simple should be.
1. open any links with the attribute with target=_blank even a one-line HTML will do:
         <a href="http://mozilla.org/" target=_blank>click me</a>

2. after the new tab was create, press ESC or click "stop loading"

3. Firefox will leave you a blank page with no URL to tell what this tab meant to go.



In reality, a tab is loading when Firefox is closed, the tab will be lost. 
User manually stops a tab loading when it take too long, the tab will be lost.
And this bug is there like forever. Ever since I started using Firefox about 2006, and if @noamtm@gmail.com recalled correctly, 2004, that is aged...
@boris This should be a kind of session lost, do you think it should be fixed on a higher priority?
Flags: needinfo?(bzbarsky)

Comment 98

2 years ago
(In reply to dindog from comment #97)
> And this bug is there like forever. Ever since I started using Firefox about
> 2006, and if @noamtm@gmail.com recalled correctly, 2004, that is aged...

It's not a matter of recalling something - the timestamp on bug 254714 is 2004-08-07 12:27 PDT.

Comment 99

2 years ago
Dunno, but if this is just about the location bar display then that's a pure UI issue.
Component: Document Navigation → Location Bar
Flags: needinfo?(bzbarsky)
Product: Core → Firefox
(In reply to Boris Zbarsky [:bz] from comment #99)

Users don't care what exact Firefox component the bug is related to. They just suffer for years and would like to have this finally fixed, whether this is a pure UI issue or not.

Comment 101

2 years ago
(In reply to Boris Zbarsky [:bz] from comment #99)
> Dunno, but if this is just about the location bar display then that's a pure
> UI issue.

I think this is an internal interface issues, the related interface got the about:blank too, such as add-on to call.
Component: Location Bar → Document Navigation
Product: Firefox → Core
Version: unspecified → Trunk

Comment 102

2 years ago
(In reply to Boris Zbarsky [:bz] from comment #99)
> Dunno, but if this is just about the location bar display then that's a pure
> UI issue.

If it's just a URL was shown or not, that is a UI issue. If you read the replies, you will understand it's not. Something is missing. A tab's session would lost.

People won't reply every after a month or two to plead here for minor UI issue. Not some many people.
It has been explained numerous times. This is not a painting issue. The URL is actually lost.

When an URL is loaded it is submitted into some API which tries to load it and ONLY AFTER IT IS LOADED it SETS THE URL IN THE LOCATION BAR.

This means that if you already have a page loaded the URL in the location bar is what is shown in the content area both during loading and after the new content starts to render.

This unfortunately does not work well with the way new tabs are opened. Internally a new tab showing about:blank is opened and the URL that's supposed to show in the tab is submitted to the same API that tries to load it and only AFTER it loads sets the URL in the location bar. It also sets the URL properly after a timeout occurs.

This means

1) you do not see what is loading because the location bar shows about:blank. The status should show which server is contacted but not exact URL.
2) if you try to reload the page before timeout occurs, cancel page loading, or the browser crashes the URL is lost. It may be lost under some other obscure circumstances as well.

So this behaviour does not match user expectation. To fix it the API for opening new window/tab needs to be amended so it *can* show the URL to be loaded from the very start and skip the about:blank phase.

It was probably done once to fix this issue but was broken again when something was redesigned without taking this special case into account, again.
(In reply to Michal 'hramrach' Suchanek from comment #103)
> When an URL is loaded it is submitted into some API which tries to load it
> and ONLY AFTER IT IS LOADED it SETS THE URL IN THE LOCATION BAR.
And if that happens, it tells this is an UI issue. UI should update the location bar first.
It is Firefox UI code which decides which way it uses docshell.


> So this behaviour does not match user expectation. To fix it the API for
> opening new window/tab needs to be amended so it *can* show the URL to be
> loaded from the very start and skip the about:blank phase.
API to open tabs is part of the Firefox UI.
Component: Document Navigation → Location Bar
Product: Core → Firefox
Duplicate of this bug: 1254304
Comment hidden (advocacy)

Updated

a year ago
Duplicate of this bug: 1265109
Comment hidden (advocacy)

Comment 109

9 months ago
this bug hunts my firefox experience everyday. my internet is not really reliable (from Iran) and if a website doesn't load and I usually load a lot of tabs then I lose that website because the address bar of that tab is empty.
this means that ,as others have said, if you cancel the url request it actually gets deleted from address bar and there is no way to recover it.
again it seems that firefox needs to get some response or maybe a timeout to even show the requested url. it wasn't like this before (I am not sure but I think this happened with firefox 4)

it this a technical limitation? is there a workaround?

Updated

8 months ago
Blocks: 1323583

Comment 110

8 months ago
(In reply to Olli Pettay [:smaug] from comment #104)
> (In reply to Michal 'hramrach' Suchanek from comment #103)
> > When an URL is loaded it is submitted into some API which tries to load it
> > and ONLY AFTER IT IS LOADED it SETS THE URL IN THE LOCATION BAR.
> And if that happens, it tells this is an UI issue. UI should update the
> location bar first.
> It is Firefox UI code which decides which way it uses docshell.

bug 103720 does this?
Duplicate of this bug: 1223847
No longer blocks: 1323583
Duplicate of this bug: 1323583
This is causing dataloss (URL) in some cases, especially on slow ISPs and when closing not fully loaded website pages.
Severity: normal → critical
Keywords: dataloss, reproducible

Updated

7 months ago
Severity: critical → normal
Summary: Open new tab with url directly instead of opening blank tab and loading url → Show pending URL in location bar (and store for session restore) for tabs with no history, non-web-controlled about:blank loaded and a pending new URL
Comment hidden (advocacy)

Comment 115

7 months ago
(In reply to Marat Tanalin | tanalin.com from comment #114)
> It would be nice to have some real progress instead of just changing the
> bug's severity and summary back and forth.

This bug is pretty non-trivial to fix. Contrary to what your comment suggests, the summary had never been changed since it was filed, and had become inaccurate - the approach it suggested was tried and rejected a few years ago. Hopefully the more accurate summary will help in getting this addressed, but as should be obvious (or it would have happened by now), that is not easy. I believe some of the work I have been doing in deps of bug 1247816 will help in addressing this bug.

The TL;DR of how I think this should be approached is now in the bug's summary. A slightly longer version: have URLBarSetURI and friends check the state I noted in the summary, and point to the loading URI if appropriate. For that to happen we probably need to store the loading/pending URI somewhere on the XUL <browser> (maybe from the tabbrowser's tabs progress listener), in order to restore it if you switch tabs etc., and consult it in sessionrestore code as well. Sessionstore can probably just store that URL as the 'loaded' URL (with no other history entries), and then restoring that tab after closing / quitting should do the Right Thing (ie start loading it again, once again triggering it being saved as the 'pending' URL... maybe there's already infrastructure for that right now, I'm not sure off-hand... I *think that restoring a tab with a single load, then closing it before it loads, then reopening it again, already does the right thing - why does that work and not this?). But I haven't verified that that approach works - I just suspect that it will. I don't have time right now to actually attempt it, write the automated tests to prevent regressing it, and fix up any other test failures that doing this work might cause.

Please consider not being so dismissive of people's attempts to update bugs to bring them closer to resolution, even in small ways.
(In reply to comment #115)
Thanks for the details, Gijs. Your intent is now more clear. It would probably have made sense to provide these details right before changing the summary.

Fwiw, I consider the bug quite critical for the entire Mozilla since it severely affects user experience and competitive ability of Firefox.

Comment 117

6 months ago
http://bbs.kafan.cn/forum.php?mod=redirect&goto=findpost&ptid=1699919&pid=37477965  someone make a uc.js to solve this ,it works but lead some other problem  



gBrowser.addEventListener("click", function(event) {
    if (!event.ctrlKey && 1 === event.which) {
        let target = event.target;
        while (target) {
            if (target.tagName && "BODY" === target.tagName.toUpperCase()) break;
            if (target.tagName && "A" === target.tagName.toUpperCase() &&
                target.target && "_BLANK" === target.target.toUpperCase() &&
                target.href && !target.href.match(/^javascript/)) {
                event.preventDefault();
                event.stopPropagation();
                openUILink(target.href);
                break;
            }
            target = target.parentNode;
        }
    }
}, true);

Comment 118

5 months ago
(In reply to :Gijs from comment #115)
> (In reply to Marat Tanalin | tanalin.com from comment #114)
> > It would be nice to have some real progress instead of just changing the
> > bug's severity and summary back and forth.
> 
> This bug is pretty non-trivial to fix. Contrary to what your comment
> suggests, the summary had never been changed since it was filed, and had
> become inaccurate - the approach it suggested was tried and rejected a few
> years ago. Hopefully the more accurate summary will help in getting this
> addressed, but as should be obvious (or it would have happened by now), that
> is not easy. I believe some of the work I have been doing in deps of bug
> 1247816 will help in addressing this bug.
> 
> The TL;DR of how I think this should be approached is now in the bug's
> summary. A slightly longer version: have URLBarSetURI and friends check the
> state I noted in the summary, and point to the loading URI if appropriate.
> For that to happen we probably need to store the loading/pending URI
> somewhere on the XUL <browser> (maybe from the tabbrowser's tabs progress
> listener), in order to restore it if you switch tabs etc., and consult it in
> sessionrestore code as well. Sessionstore can probably just store that URL
> as the 'loaded' URL (with no other history entries), and then restoring that
> tab after closing / quitting should do the Right Thing (ie start loading it
> again, once again triggering it being saved as the 'pending' URL... maybe
> there's already infrastructure for that right now, I'm not sure off-hand...
> I *think that restoring a tab with a single load, then closing it before it
> loads, then reopening it again, already does the right thing - why does that
> work and not this?). But I haven't verified that that approach works - I
> just suspect that it will. I don't have time right now to actually attempt
> it, write the automated tests to prevent regressing it, and fix up any other
> test failures that doing this work might cause.
> 
> Please consider not being so dismissive of people's attempts to update bugs
> to bring them closer to resolution, even in small ways.

This bug is still present in FF53 esr & FF54.
And it looks critical as data loss is happening especially on slow 2g/3g or latency problems.

Is anyone looking into this? It's fairly reproducible .(In reply to Marat Tanalin | tanalin.com from comment #116)
> (In reply to comment #115)
> Thanks for the details, Gijs. Your intent is now more clear. It would
> probably have made sense to provide these details right before changing the
> summary.
> 
> Fwiw, I consider the bug quite critical for the entire Mozilla since it
> severely affects user experience and competitive ability of Firefox.

Yes and also DATA LOSS is a major concern.
Flags: needinfo?(gijskruitbosch+bugs)

Comment 119

5 months ago
Sorry if not clear

reddit images or sites sometimes keep loading then convert to newtab on weak 2g/3g connections instead of showing problem loading pages, and site info is lost.

PS: sorry if wrong bug- guide to right one is appreciated

Comment 120

5 months ago
(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #113)
> This is causing dataloss (URL) in some cases, especially on slow ISPs and
> when closing not fully loaded website pages.

This is happening even if the browser is not closed.
it keep loading then convert to newtab especially with tab heavy browsing.

Updated

5 months ago
Flags: needinfo?(Virtual)
Yes. That's what this issue is about.
Loss of the data, which is critical severity per - https://wiki.mozilla.org/BMO/UserGuide/BugFields#importance
Severity: normal → critical
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(Virtual)

Comment 122

5 months ago
problem hits especially when suddenly while loading(progress to load eg page name on tab) they turn into new tab ie DATA lost

Can this be fixed and uplifted into ESR52?

Comment 123

4 months ago
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me) from comment #121)
> Yes. That's what this issue is about.
> Loss of the data, which is critical severity per -
> https://wiki.mozilla.org/BMO/UserGuide/BugFields#importance

This problem is getting worse and none knows why this is happening.

Comment 124

4 months ago
A variant of this bug also happens on Firefox for Android. And it is, indeed, getting worse. 

And the first variant of this bug was reported in 2004!

Comment 125

4 months ago
(In reply to Noam Tamim from comment #124)
> A variant of this bug also happens on Firefox for Android. And it is,
> indeed, getting worse. 
> 
> And the first variant of this bug was reported in 2004!

Tested it today on FF55 android and it happens quite often now, and no one seems to be working on fixing it. Switching to chrome on all until this bug is looked into and fixed, or not fixed and hits release and blows up :)
(In reply to Sunil Kumar from comment #125)
> (In reply to Noam Tamim from comment #124)
> > A variant of this bug also happens on Firefox for Android. And it is,
> > indeed, getting worse. 
> > 
> > And the first variant of this bug was reported in 2004!
> 
> Tested it today on FF55 android and it happens quite often now, and no one
> seems to be working on fixing it. Switching to chrome on all until this bug
> is looked into and fixed, or not fixed and hits release and blows up :)

Problems in Firefox for Android need to be filed and investigated separately.

Also, if this has gotten worse on desktop, please file a separate bug so we can look into that specifically. Fixing a specific regression might be less complicated than fixing this bug.
Blocks: 1330633

Comment 127

4 months ago
I've encountered this again in Firefox 52, and it has gotten worse.  It now happens in about=_blank but also in right-click new-tab.

I've made two screencasts.  I'm not uploading them until I get permission because they are 1.5 MB.

I tested it on slashdot.org and theguardian.com.  I believe that whatever CDN the guardian is using is currently unavailable in this country, which is what's causing the problem.  These websites are large, and should be familiar to most users here.  99% of websites are working.

Steps (click to open):
1. go to a slashdot story that references theguardian.
     https://yro.slashdot.org/story/17/04/06/2049209/uber-contract-gibberish-says-mp-investigating-gig-economy
2. click on the link
3. new tab opens, URL bar shows about:blank
4. status shows "Looking up www.theguardian.com"
5. a second later, status shows "Connecting to www.theguardian.com"
     url bar still shows about:blank
6. 90 seconds later Firefox gives up.
7. URL bar shows about:blank

Steps (right click, new tab):
1. go to a slashdot story that references theguardian.
     https://yro.slashdot.org/story/17/04/06/2049209/uber-contract-gibberish-says-mp-investigating-gig-economy
2. right click, open in new tab
3. new tab opens, URL bar shows https://www.theguardian.com/technology/2017/apr/06/uber-contract-gibberish-says-mp-investigating-gig-economy
4. status shows "connecting to www.theguardian.com"
     assumption: IP is in the DNS cache
5. URL bar continues to show the URL
6. 90 seconds later firefox gives up.
7. URL bar shows about:blank (refresh impossible.)

So in the first case the URL bar was never filled in, but in the second case the URL bar had the information and lost it.

I did a network dump, and I see a TCP SYN, and a few retransmissions, but never a SYN ACK.
(In reply to Berend De Schouwer from comment #127)
> I've encountered this again in Firefox 52, and it has gotten worse.  It now
> happens in about=_blank but also in right-click new-tab.

Again, recent regressions should be filed separately. Do you have a regression range?

Comment 129

4 months ago
(In reply to Berend De Schouwer from comment #127)
> I've encountered this again in Firefox 52, and it has gotten worse.  It now
> happens in about=_blank but also in right-click new-tab.
> 
> I've made two screencasts.  I'm not uploading them until I get permission
> because they are 1.5 MB.
> 
> I tested it on slashdot.org and theguardian.com.  I believe that whatever
> CDN the guardian is using is currently unavailable in this country, which is
> what's causing the problem.  These websites are large, and should be
> familiar to most users here.  99% of websites are working.
> 
> Steps (click to open):
> 1. go to a slashdot story that references theguardian.
>     
> https://yro.slashdot.org/story/17/04/06/2049209/uber-contract-gibberish-says-
> mp-investigating-gig-economy
> 2. click on the link
> 3. new tab opens, URL bar shows about:blank
> 4. status shows "Looking up www.theguardian.com"
> 5. a second later, status shows "Connecting to www.theguardian.com"
>      url bar still shows about:blank
> 6. 90 seconds later Firefox gives up.
> 7. URL bar shows about:blank
> 
> Steps (right click, new tab):
> 1. go to a slashdot story that references theguardian.
>     
> https://yro.slashdot.org/story/17/04/06/2049209/uber-contract-gibberish-says-
> mp-investigating-gig-economy
> 2. right click, open in new tab
> 3. new tab opens, URL bar shows
> https://www.theguardian.com/technology/2017/apr/06/uber-contract-gibberish-
> says-mp-investigating-gig-economy
> 4. status shows "connecting to www.theguardian.com"
>      assumption: IP is in the DNS cache
> 5. URL bar continues to show the URL
> 6. 90 seconds later firefox gives up.
> 7. URL bar shows about:blank (refresh impossible.)
> 
> So in the first case the URL bar was never filled in, but in the second case
> the URL bar had the information and lost it.
> 
> I did a network dump, and I see a TCP SYN, and a few retransmissions, but
> never a SYN ACK.

Just to add this is happening in Firefox 52/53/54/55 too. 
Happens on all major sites even imgur image urls, so CDN used is currently unavailable in this country, which is what's causing the problem..
is not the issue!


How to make screen-cast?
  

(In reply to Dão Gottwald [::dao] from comment #128)
 
> Again, recent regressions should be filed separately. Do you have a
> regression range?


Not original poster but if correctly remember this
Firefox 51 is not affected by this so the regression there?

Comment 130

4 months ago
@Dão Gottwald:

I'll try.  It involves setting up VMs with Firefox versions and custom firewalls (to drop SYN ACK) to find out which version added the same problem to right-click as left-click.

I've got no idea if it's possible to add network failures to Firefox build unit tests.


@sunil kumar:

I know that an unavailable CDN isn't the root cause.  It's just triggering the bug *right* *now* for me.  I was using it as an example trigger.  I think the dropped SYN ACK is more important.

The screen-cast was done using a Gnome Shell feature, not a Firefox feature.

Comment 131

4 months ago
@Dão Gottwald:

> I know that an unavailable CDN isn't the root cause.  It's just triggering
> the bug *right* *now* for me.  I was using it as an example trigger.  I
> think the dropped SYN ACK is more important.
> 
> The screen-cast was done using a Gnome Shell feature, not a Firefox feature.

Thanks, try Firefox 51 & 52 sure the start is there.
No idea for screen-cast ,would tried to show on slow connections it's regular problem.

Comment 132

4 months ago
I've opened #1354796 for the regression on right-click->open in new tab.

A note on testing the fix: the cache must be empty.  If the unavailable site is in the browser cache, the URL bar will not revert to about:blank.  This may be relevant to testing this bug too.
Duplicate of this bug: 1352447
Attachment #493584 - Attachment is obsolete: true

Comment 134

2 months ago
Created attachment 8869123 [details]
Clipboard01.jpg

how come his has not been fixed since firefox 52?
It is on release and causing data loss and no one here seems to bother to fix this?

Comment 135

2 months ago
@Sami: As you seem to care, please feel encouraged to provide a software patch. Thanks in advance for your help!

Comment 136

2 months ago
(In reply to Andre Klapper from comment #135)
> @Sami: As you seem to care, please feel encouraged to provide a software
> patch. Thanks in advance for your help!

Sure will take you up on the offer just allow me access to bug 1284395
and will try to patch it up myself :)
will i get a bounty too for doing paid devs job?

waiting for your approval!

(In reply to jigsawmode from comment #131)
> @Dão Gottwald:
> 
> > I know that an unavailable CDN isn't the root cause.  It's just triggering
> > the bug *right* *now* for me.  I was using it as an example trigger.  I
> > think the dropped SYN ACK is more important.
> > 
> > The screen-cast was done using a Gnome Shell feature, not a Firefox feature.
> 
> Thanks, try Firefox 51 & 52 sure the start is there.
> No idea for screen-cast ,would tried to show on slow connections it's
> regular problem.

Same thing here v51 works well but in v52-55 like the attachment some tabs load some turn blank with all data in it destroyed
even if the network is fine.(In reply to Berend De Schouwer from comment #127)
> I've encountered this again in Firefox 52, and it has gotten worse.  It now
> happens in about=_blank but also in right-click new-tab.
> 
> I've made two screencasts.  I'm not uploading them until I get permission
> because they are 1.5 MB.
> 
> I tested it on slashdot.org and theguardian.com.  I believe that whatever
> CDN the guardian is using is currently unavailable in this country, which is
> what's causing the problem.  These websites are large, and should be
> familiar to most users here.  99% of websites are working.
> 
> Steps (click to open):
> 1. go to a slashdot story that references theguardian.
>     
> https://yro.slashdot.org/story/17/04/06/2049209/uber-contract-gibberish-says-
> mp-investigating-gig-economy
> 2. click on the link
> 3. new tab opens, URL bar shows about:blank
> 4. status shows "Looking up www.theguardian.com"
> 5. a second later, status shows "Connecting to www.theguardian.com"
>      url bar still shows about:blank
> 6. 90 seconds later Firefox gives up.
> 7. URL bar shows about:blank
> 
> Steps (right click, new tab):
> 1. go to a slashdot story that references theguardian.
>     
> https://yro.slashdot.org/story/17/04/06/2049209/uber-contract-gibberish-says-
> mp-investigating-gig-economy
> 2. right click, open in new tab
> 3. new tab opens, URL bar shows
> https://www.theguardian.com/technology/2017/apr/06/uber-contract-gibberish-
> says-mp-investigating-gig-economy
> 4. status shows "connecting to www.theguardian.com"
>      assumption: IP is in the DNS cache
> 5. URL bar continues to show the URL
> 6. 90 seconds later firefox gives up.
> 7. URL bar shows about:blank (refresh impossible.)
> 
> So in the first case the URL bar was never filled in, but in the second case
> the URL bar had the information and lost it.
> 
> I did a network dump, and I see a TCP SYN, and a few retransmissions, but
> never a SYN ACK.

You can reproduce it just by stressing the network
Flags: needinfo?(dao+bmo)
Flags: needinfo?(berend.de.schouwer)

Comment 137

2 months ago
(In reply to Sami from comment #136)
> (In reply to Andre Klapper from comment #135)
> > @Sami: As you seem to care, please feel encouraged to provide a software
> > patch. Thanks in advance for your help!
> 
> Sure will take you up on the offer just allow me access to bug 1284395
> and will try to patch it up myself :)

I've asked for the bug to be opened up. But reverting that security fix entirely will likely not be considered acceptable.

> will i get a bounty too for doing paid devs job?

No. I was a volunteer for much longer than I've been a paid employee. There are plenty of benefits to volunteering, but being paid isn't one of them.

> (In reply to jigsawmode from comment #131)
> > Thanks, try Firefox 51 & 52 sure the start is there.
> > No idea for screen-cast ,would tried to show on slow connections it's
> > regular problem.
> 
> Same thing here v51 works well but in v52-55 like the attachment some tabs
> load some turn blank with all data in it destroyed

Someone really needs to come up with a reproducible testcase that "works well" in 51 but not in 52. My earlier impression was that that's covered by bug 1354796. Inasmuch as it's not, we need a separate bug, as Dão has already said.

The original bug well predates 52. The only change, I think, is that in some circumstances, we will explicitly display about:blank (rather than an empty URL bar) for pages that could potentially be controlled by web content. If the new page fails to load, I guess we used to then get 'stuck' on an empty URL bar, and now we get 'stuck' on about:blank. The consequence is the same...

> You can reproduce it just by stressing the network

That's really not detailed enough. It likely depends on the network and the exact pages you're loading anyway.

The needinfo flag is intended for cases where you need specific information from a specific person / specific people. I don't see any questions here for Dão and Berend, so I'm clearing the flag.
Flags: needinfo?(dao+bmo)
Flags: needinfo?(berend.de.schouwer)

Comment 138

2 months ago
(In reply to :Gijs from comment #137)
> > You can reproduce it just by stressing the network
> 
> That's really not detailed enough. It likely depends on the network and the
> exact pages you're loading anyway.
> 
Try comment 97.

Comment 139

2 months ago
(In reply to dindog from comment #138)
> (In reply to :Gijs from comment #137)
> > > You can reproduce it just by stressing the network
> > 
> > That's really not detailed enough. It likely depends on the network and the
> > exact pages you're loading anyway.
> > 
> Try comment 97.

... yes, but that's not a regression with 52, which is what the recent comments are about.
You need to log in before you can comment on or make changes to this bug.