Closed Bug 610357 Opened 14 years ago Closed 1 year ago

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

Categories

(Firefox :: Address Bar, defect, P3)

Product:
Firefox
Component:
Address Bar
Type:
defect
Points:
13

Tracking

()

Status:
RESOLVED FIXED
Milestone:
113 Branch
Tracking Flags:
Tracking Status
firefox-esr102 --- wontfix
firefox111 --- wontfix
firefox112 --- wontfix
firefox113 --- fixed

People

(Reporter: tabutils+bugzilla, Assigned: daisuke)

References

(Blocks 2 open bugs,
URL
)

Details

(Keywords: dataloss, reproducible, Whiteboard: [snt-scrubbed][search-papercut])

Attachments

(2 files, 2 obsolete files)

Clipboard01.jpg
60.58 KB, image/jpeg
Details
Bug 610357: Show pending URL in location bar and tab while loading.
48 bytes, text/x-phabricator-request
Details | Review 
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
Blocks: cuts-tabs
Actually I think bug 514310 fixed this, but that patch was part of Firefox 3.6 already...
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.
No longer blocks: cuts-tabs
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
URL: data:text/html,<a href=http://mozilla...
OS: Windows XP → All
Hardware: x86 → All
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?
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.
I see.  Is there a reason we can't update the location bar when the load starts in the special case of initial loads?
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?
And just so we're clear on expectations, we're talking post-2.0 stuff here, right?
(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.
> 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.
> 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.
> 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.
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.
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 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 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.
Attached patch patch (obsolete) — — Splinter Review 
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
Attached patch patch (obsolete) — — Splinter Review 

        Attachment #493573 -
        Attachment is obsolete: true

        Attachment #493584 -
        Flags: review?(bzbarsky)

    
    

    
  
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.

    
    

    
  
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.

    
    

    
      
  

    
    

    
  
> 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.

    
    

    
  
> 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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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>....

    
    

    
  
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.

    
    

    
  
> 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?

    
  
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.

    
  
Assignee: dao → nobody
Status: ASSIGNED → NEW

    
    

    
      
  

    
    

    
  
(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).

    
    

    
  
Bug 569047 has code that shows that this also disturbs code that tries to wait for the page to load.

    
    

    
  
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?

    
    

    
  
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.

    
    

    
  
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.

    
    

    
      
  

    
    

    
  
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.

    
    

    
  
The blank url bar issue is NOT this bug.  It's a pure UI issue.

    
    

    
  
(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(...);
}

    
    

    
  
> 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.

    
    

    
  
(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.

    
    

    
  
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

    
    

    
      
  

    
    

    
  
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.

    
    

    
      
  

    
    

    
  
Patches for the bug are certainly welcome.

Bug 878747 may have made this easier to fix.

    
    

    
      
  

    
    

    
  
easy repro if i use 2 addons with getBrowser() function

    
    

    
      
  

    
    

    
  
Adding to the Triage Tracker for the Triage Team to review and consider for the Product Backlog.
Blocks: fxdesktoptriage
Flags: needinfo?(mmucci)
Flags: firefox-backlog?
No longer blocks: fxdesktoptriage
Flags: firefox-backlog? → firefox-backlog+
Whiteboard: p=13

    
    

    
  
(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.
Points: --- → 13
Flags: qe-verify?
Whiteboard: p=13

    
    

    
  
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?

    
  
See Also:  → 798249

    
  
Blocks: 1172949

    
  
Blocks: 1054740
No longer blocks: 1054740

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
(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)

    
    

    
  
(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.

    
    

    
  
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.

    
    

    
  
(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

    
    

    
  
(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

    
    

    
      
  

    
    

    
      
  

    
    

    
  
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?

    
  
Blocks: 1323583

    
    

    
  
(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?

    
    

    
  
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

    
  
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

    
    

    
      
  

    
    

    
  
(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.

    
    

    
  
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);

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
  
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)

    
    

    
      
  

    
    

    
      
  

    
    

    
  
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!

    
    

    
      
  

    
    

    
  
(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.

    
    

    
  
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?

    
    

    
      
  

    
    

    
  
@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.

    
    

    
      
  

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached image
          
        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?

    
    

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

    
    

    
  
(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)

    
    

    
  
(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)

    
    

    
  
(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.

    
    

    
  
(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.

    
    

    
  
This still happens in the new Firefox (Quantum). How come? I thought the UI is a complete rewrite.

This bug happens so many times that it hurts.
Priority: -- → P3

    
    

    
  
I just hit this again when trying to open article from Planet Mozilla RSS feed (from Feedbro reader extension).  My network connection is overloaded right now.


URL was https://marcozehe.de/2019/12/02/why-ai-will-never-replace-human-picture-descriptions/


    

  • buttons inside address bar are not visible (•••, bookmark star, etc.)
    • 

  • reload button at first is active, but after a moment (switching tabs?) changes state to inactive
    • 

  • address is at first still available in address bar, but disappears after few attempts to load page again (not easy to reproduce but most irritating)
    • 



I checked browser console, and this connection does not have response headers - timeout on headers?


I think I have a way to easily reproduce this even on very good connections - just try to load URL with 204 response - it will have response headers, but for UI behavior it will be very similar (I see no difference).


Such address can be https://www.google.com/gen_204



    
    

    
  
And now I have easy way to make address disappear from address bar:


select "Reload Tab" from tab context menu (from tab bar).



    
    

    
  
(In reply to gwarser from comment #141)




Such address can be https://www.google.com/gen_204

(In reply to gwarser from comment #142)

select "Reload Tab" from tab context menu (from tab bar).




Doing these 2 steps I can reproduce the URI disappearing. Marco, can you take a look at why this happens?


Flags: needinfo?(mak)

    
    

    
  
Are you starting from the new tab page or about:blank?


UrlbarSetURI() is invoked to restore the url to the previous state in certain cases, in particular when the request was stopped before a location change:

https://searchfox.org/mozilla-central/rev/073b138dcba41cd3f858522e5f0a9ee73e39afa0/browser/base/content/tabbrowser.js#5790

That happened as a security fix in bug 724599.


If the previous state was an initial page (about:home, about:newtab, about:blank) then the urlbar becomes empty, that was the previous state.

Feedbro always opens in a new tab for me, that means the load starts from an empty urlbar, and reverts to an empty urlbar.


I'm not sure what we want to do there, the difference between pageproxystate valid/invalid is imo still too subtle to not confuse the user regarding "what is in the urlbar is not what is loaded in content", so I don't think we can lift that fix.


Flags: needinfo?(mak)

    
    

    
  
Feedbro case was only first one. I then tried few times from new tab/new tab from bookmark.


Should not new tab content be also restored? To "Top Sites" etc.? It does not -  I see blank page. When 204 is executed from tab with page loaded (here), page is still loaded after request ends.


Maybe this security fix should be lifted for addresses loaded in new tabs? Tabs without any history?


204 case or tabs with history can be handled differently. My 204 example was only here to show how bad this looks (because it looks the same right now). You can imagine what I feel after opening dozens of tabs from RSS reader and then half are empty.



    
    

    
  
(In reply to gwarser from comment #145)




Should not new tab content be also restored? To "Top Sites" etc.? It does not -  I see blank page. When 204 is executed from tab with page loaded (here), page is still loaded after request ends.




That's a different question, for which I don't have an answer, the address bar just restores its value, doesn't really navigate again. If we could detect the specific case precisely then surely things could be improved.




Maybe this security fix should be lifted for addresses loaded in new tabs? Tabs without any history?




Maybe, but it's an edge case still, so it may not get a lot of traction.

But after all, if I'm reading it correctly, what you are asking is pretty much what this bug is about: "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". Just replace about:blank with "empty initial page".



    
    

    
  
"Firefox does not load pages. Have to open 3 tabs to get firefox to load a page"

https://www.reddit.com/r/firefox/comments/qvgehr/firefox_does_not_load_pages_have_to_open_3_tabs/


"It very often fails to load a link so I have to click on the URL and hit enter for it to retry (regular refresh does not work)."

https://www.reddit.com/r/firefox/comments/qxcdh4/firefox_is_getting_really_slow_slately/



    
    

    
      
  

    
    

    
      
  

    
    

    
  
This may still be quite annoying in countries with slow or intermittent Internet connections, the fix should probably happen on the UI side, in URLBar code, but it requires particular attention to avoid security problems (spoofing of the url).

Gijs in comment 115 pointed out some of the cases where it may be safe, we may still want to reach to platform and security to verify the appropriate way to identify those cases.


Severity: critical → S3
Whiteboard: [snt-scrubbed][search-papercut]

    
    

    
  
The severity field for this bug is relatively low, S3. However, the bug has 14 duplicates, 52 votes and 59 CCs.

:adw, could you consider increasing the bug severity?


For more information, please visit auto_nag documentation.


Flags: needinfo?(adw)

    
    

    
  
(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #151)




The severity field for this bug is relatively low, S3. However, the bug has 14 duplicates, 52 votes and 59 CCs.

:adw, could you consider increasing the bug severity?




This bug was originally opened (by me) 18 years ago (https://bugzilla.mozilla.org/show_bug.cgi?id=254714). It was fixed after a few years, and then it started happening again.



    
  
Flags: needinfo?(adw)

    
    

    
  
Changing qe-verify? to qe-verify+.


Flags: qe-verify? → qe-verify+
Assignee: nobody → daisuke
Status: NEW → ASSIGNED
Duplicate of this bug: 1809779

        Attachment #9318073 -
        Attachment description: Bug 610357: Show pending URL in location bar and tab while loading. → WIP: Bug 610357: Show pending URL in location bar and tab while loading.

        Attachment #9318073 -
        Attachment description: WIP: Bug 610357: Show pending URL in location bar and tab while loading. → Bug 610357: Show pending URL in location bar and tab while loading.

    
  
Blocks: 1824040

    
    

    
  
Pushed by dakatsuka.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b8ae8c3725cd
Show pending URL in location bar and tab while loading. r=mak,Gijs

    
    

    
  
Pushed by dakatsuka.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/112ae3734582
Show pending URL in location bar and tab while loading. r=mak,Gijs

    
  
Flags: needinfo?(daisuke)

    
    

    
  
I'm adding a note related to the fix.

What we're landing is an improvement to the overall situation with _blank targeted links, but it may not be a full coverage of any edge case, there's complex implications (included security) in many of them.

Bug 1824040 has already been filed to improve the situation re: Session Restore.


Since this bug has a really long history, and it's somewhat confusing, I'm encouraging you to file new bugs if you hit a case that was not fully fixed, rather than posting further comments here.

That will allow us to more efficiently track the single issues and solutions.



    
    

    
  
(In reply to Marco Bonardo [:mak] from comment #159)




Since this bug has a really long history, and it's somewhat confusing, I'm encouraging you to file new bugs if you hit a case that was not fully fixed, rather than posting further comments here.

That will allow us to more efficiently track the single issues and solutions.




Re the history of this bug, I feel obligated to mention that it's first incarnation was reported by yours truly, 19 years ago.

https://bugzilla.mozilla.org/show_bug.cgi?id=254714



    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/112ae3734582


Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 1 year ago

          status-firefox113:
          --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 113 Branch

    
  
Regressions: 1830732

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: