Closed Bug 254714 Opened 20 years ago Closed 13 years ago

while loading a page, on a new tab/window, the location bar does not display the address URL

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.1b1

People

(Reporter: noamtm, Assigned: dao)

References

(
URL
)

Details

(Whiteboard: [testday-20110422])

Attachments

(1 file, 5 obsolete files)

patch
6.05 KB, patch
Gavin
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

When I click on a link to open it in a new window or tab, and the page takes
time to load (it takes time before I see ANY content - maybe a budy server or a
congested network), the location bar is blank, instead of displaying the address
it tries to load. I imagine it always happens, but only after the page is at
least partially loaded, the URL is displayed.

Reproducible: Always
Steps to Reproduce:



Expected Results:  
Fill the location bar with URL being loaded BEFORE trying to load that URL.
Bug 231393 has been fixed, but not for external links it seems?
*** Bug 261453 has been marked as a duplicate of this bug. ***
*** Bug 263497 has been marked as a duplicate of this bug. ***
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Keywords: dataloss
The odds of this being fixed for 1.0 are rather slim, but this is a pretty
visible bug with no real explanation for a non-clueful user.  Given the nature
of XUL it would seem to be moderately simple to fix (or hack for 1.0 if
necessary).  Nominating, tho I don't really expect this to be plussed...
Flags: blocking-aviary1.0?
Sorry for the duplicate, I used the search engine but did not find anything.

This bugs causes to loss the address when you open an invalid link directly to a
new window. On the other hand, if you open an invalida link to a new tab, the
address is kept.
yeah, we would need a good well tested patch to take this for 1.0.  I'm not sure
why the dataloss keyword is on this?
Flags: blocking-aviary1.0? → blocking-aviary1.0-
This is a form of dataloss. If you are opening a large number of links in tabs
at once, and one or two of them fail to load, it is laborious in the extreme to
go back to the original page, IF you still have it open, and check the status
bar to discern which links were bad.
*** Bug 268856 has been marked as a duplicate of this bug. ***
José (comment #1):

If by "external links" you mean URLs typed by the user, you're right,
that was fixed in bug 231393, otherwise I'd like to point out that
this problem seems to exist for all kinds of links/URLs (page links,
bookmarks, history, links from external applications etc.).

(In reply to comment #9)
> If by "external links" you mean URLs typed by the user, you're right,

I meant links clicked on external applications, like tb. If server is down or
anything the tab url will be blank.
(In reply to comment #10)
> I meant links clicked on external applications, like tb. If server is down or
> anything the tab url will be blank.

Sorry, I had misread comment #1. Anyway, the point was that the location bar
will not only be (initially) blank for URLs launched by external applications
but for other links (including regular page links and bookmarks) as well.
All of this probably has the same root cause of which bug 231393 has fixed only
one aspect.
*** Bug 268112 has been marked as a duplicate of this bug. ***
*** Bug 269870 has been marked as a duplicate of this bug. ***
*** Bug 270330 has been marked as a duplicate of this bug. ***
*** Bug 272786 has been marked as a duplicate of this bug. ***
*** Bug 272844 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
*** Bug 280455 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1? → blocking-aviary1.1-

*** This bug has been marked as a duplicate of 286320 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
*** Bug 286320 has been marked as a duplicate of this bug. ***
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 286335 has been marked as a duplicate of this bug. ***
*** Bug 288934 has been marked as a duplicate of this bug. ***
*** Bug 211856 has been marked as a duplicate of this bug. ***
It seems that a patch for this bug has been posted at

Bug 231393

https://bugzilla.mozilla.org/show_bug.cgi?id=231393
*** Bug 291863 has been marked as a duplicate of this bug. ***
*** Bug 295064 has been marked as a duplicate of this bug. ***
*** Bug 295441 has been marked as a duplicate of this bug. ***
This is a very annoying bug that I would really like to see fixed. It exists in
both Mozilla 1.7.8 and Firefox 1.0.4, and occurs very often when I open several
links in new tabs in a short period of time by middle-clicking.

I've had to train myself to keep the original page(s) with the links open in
case the tabs time out and fail to load before Mozilla/Firefox decides to
populate the address bar.
New to bugzilla, hope I'm in the right place.  I just wanted to add that on
**** link (like this satellite I'm on in Iraq), this bug causes me heartache.
i.e. (pun intented) when surfing slashdot, I like to open all the interesting
stories in a new tab.  I often get done with the index only to find all of my
tabs are empty due to DNS giving up on my laggy connection.
*** Bug 302587 has been marked as a duplicate of this bug. ***
*** Bug 302923 has been marked as a duplicate of this bug. ***
Assignee: bugs → nobody
Status: REOPENED → NEW
QA Contact: davidpjames → location.bar
Please tell me, WHEN will this be fixed??
(In reply to comment #31)
> Please tell me, WHEN will this be fixed??

Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before
making any more comments. (sorry to everyone else for the bugspam)

You are of course welcome to submit a patch to this bug to fix the issue.
It seems like this is fixed in Deer Park Alpha 2, but I haven't done any
extensive testing yet.
Flags: blocking-aviary2.0?
Yes, this bug seems to be fixed in FF 1.5 Beta 1.  Can we get a few other
confirmations so we can mark this fixed?
WFM here on the latest beta on XP SP2!  :-D
(In reply to comment #34)
> Yes, this bug seems to be fixed in FF 1.5 Beta 1.  Can we get a few other
> confirmations so we can mark this fixed?

This is fixed in v1.5, but the problem remains for links opened in a new window
and with links opened via external applications.

From the original filing:

"When I click on a link to open it in a new window . . ."
reply to comment #36)
> This is fixed in v1.5, but the problem remains for links opened in a new
window > and with links opened via external applications.

Being the original reporter of this bug, I can confirm this. Note that (with
1.5b1) when openning a link in a new tab, the address bar of that tab gets
filled with the URL *before* trying to fetch the page; but on a new window, you
first get an empty address bar, and only after loading the page you have the URL
there.
Attached patch FF 1.5 Beta 1 patch (obsolete) — — Splinter Review 
Okay.  I have uploaded a patch.  It works by delaying the call (via setTimeout)
to getWebNavigation().loadURI() to allow XUL to update url bar.
(In reply to comment #37)
> reply to comment #36)
> > This is fixed in v1.5, but the problem remains for links opened in a new
> window > and with links opened via external applications.
> 
> Being the original reporter of this bug, I can confirm this. Note that (with
> 1.5b1) when openning a link in a new tab, the address bar of that tab gets
> filled with the URL *before* trying to fetch the page; but on a new window, you
> first get an empty address bar, and only after loading the page you have the URL
> there.

Not sure if this is related or a separate bug, but I notice when I clear
history, that if I hit "reload" ("refresh"), nothing shows up; but if I hit
"go", the history now shows one item. Hope this somehow gives a clue to help.
Comment on attachment 196570 [details] [diff] [review]
FF 1.5 Beta 1 patch

Hmm... I thought I set the review flag on this patch, but appearently not...
well, setting it now.
Attachment #196570 - Flags: review?(mconnor)
Comment on attachment 196570 [details] [diff] [review]
FF 1.5 Beta 1 patch

*sigh* used the wrong email/bugmail.  Updating...
Attachment #196570 - Flags: review?(mconnor) → review?(mconnor)
I think this is fixed in 1.5?
WFM.
Yes, it's fixed.
Not yet fixed in the trunk
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051201 Firefox/1.6a1
Attached image Image showing 1.5 not fixed? (obsolete) — 
Is this the same bug?
I notice that when opening new tabs/windows, the URL is shown in the location bar, but when it's the same window/tab, such as a Search or a Bookmark or History, there is no URL shown.
As lo(In reply to comment #45)
> Created an attachment (id=204896) [edit]
> Image showing 1.5 not fixed?
> 
> Is this the same bug?
> I notice that when opening new tabs/windows, the URL is shown in the location
> bar, but when it's the same window/tab, such as a Search or a Bookmark or
> History, there is no URL shown.

As long as the address comes up eventually (which it does when the pages is loaded) there's no problem. The question is what happens if the connection times out or fails in some other way. If the address still comes up then I consider this bug closed, others might have a different oppinion.


Things are a lot better now that the error page provides the URL after a failure.  However, the original spirit of this bug seems to be about the timing.  I think some of us read this and thought about other bugs about how frustrating it was when you opened 100 new tabs and half of them failed with no URL.  This sounds more so about how the timing works in terms of showing the URL before the page starts loading.  As unimportant as it sounds, this bug matters to some people, and I doubt it'd be too hard to implement.  I am very happy about the 1.5 load error page, though.  Thanks for that.  
(In reply to comment #47)

Since I'm the one that reported this bug, let me clarify. First, in the description there's a typo: "budy" should be "busy" - as in a busy server. Back in version 0.9, when you opened a few tabs from links, and some would fail (for example, if they are slashdotted) - you'd get blank tabs with no URLs. This is what annoyed me then, and it is fixed now.
What is still not fixed is the same, but when opening in windows instead of tabs. I don't know how difficult it is to fix, but it's much less annoying; it is not that easy to open many links in WINDOWS (you have to jump to your original window after any link). Plus, I do remember that I added the "or window" just for completeness.

Anyway - I'd leave it open and change the severity from major to minor. 
Certainly not fixed for 'target="_blank"'.
> As long as the address comes up eventually (which it does when the pages is
> loaded) there's no problem.

I disagree. I reported (a duplicate of) this bug precisely because it is very annoying that the URL doesn't come up until the page starts loading. Often I just want to know what URL it is loading; sometimes I would like to copy the URL to the clipboard; sometimes I need to cancel and later reload. All of these three things currently require me to wait for the page to start loading, which depending on the server can take very long. Please fix this and have it display the URL immediately.
Has anyone tried/reviewed the patch I submitted nearly three months ago?  I just applied it to 1.5 RC3 and it still works fine, as far as I can tell.

Note: There are known patch review issues (see http://developer.mozilla.org/devnews/index.php/2005/11/16/patch-review-issues/), which most likely explains why this patch has not yet been reviewed.
Attached patch FF 1.5 RC3 patch (obsolete) — — Splinter Review 
I have updated the patch to match RC3 (and decreased the timer interval from 10ms to 0ms).  For those not afraid to manually update a file inside a .jar (it's really easy), take a look at the diff and use it to update browser.jar.  Confirm that the patch works or doesn't.  This way, we can talk about why the patch hasn't been applied rather than whether the bug still exists or not...
Attachment #196570 - Attachment is obsolete: true
Attachment #204969 - Flags: review?
Attachment #196570 - Flags: review?(mconnor)
Comment on attachment 204969 [details] [diff] [review]
FF 1.5 RC3 patch

I can't reproduce this on trunk or branch, but we're not going to use setTimeout for every single loadURI call.
Attachment #204969 - Flags: review? → review-
Clearing blocking request, unable to reproduce, except from external links, but that's not really a blocker (and its unlikely to be datalossy since its almost certainly not user-typed outside of the app)
Flags: blocking-firefox2?
Okay then, is there a way to force a window (or XUL element) refresh in the middle of script?  As I noted in Comment #38, the use of setTimeout was to allow the window to update itself since it doesn't apprear to do this asynchronously.  I am prefectly happy to use another approach if you can give a suggestion.
Maybe this issue results form bug 266627?
[using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3]

There's another variant of this bug. I'm not sure if it should be its own bug:
when the usage of a proxy server is required on the network (usually in a workplace) - and "direct connection to the Internet" is set - any tab/window that opens either from an external application or from a link that opens in a new window will have a blank location bar. 
This is annoying, because even after enabling the proxy (with some extension like ProxyButton), you can't click Refresh to load the page.

BTW: in the original bug description, "budy" should be "busy". My bad. "s" and "d" are next to each other, and Firefox 0.9 had no speller..
On FF2.0b1 build 2006071003:

I think this also happens as a result of the new policy on connecting to SSLv2 sites.  

1. go to this post: http://forums.mozillazine.org/viewtopic.php?p=2364949#2364949
2. find the link to https://webmail.shaw.ca/ .  and click on it.
3. observe that it opens a new tab and then Firefox throws an error about it using SSLv2 (can't connect securely to site).
4. look at the address bar, the webmail.shaw.ca site is not up there.
5. If you go back to the post and right-click and select open-in-new-tab, then you get the same error, but the address shows up.
6. If you go back to the post and right-click and select open-in-new-window, then you get the same error and no address (this is as described in comments 36, 37, and others).

Could the difference in behavior between clicking on the link versus using right-click open-in-new-tab be due to javascripting?

Reference link about SSLv2 changes: http://wiki.mozilla.org/Necko:SSL_v2_Sites 
(In reply to comment #35)
> WFM here on the latest beta on XP SP2!  :-D
> 

Still happening on

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060928 Minefield/3.0a1 ID:2006092821 [cairo]
*** Bug 361156 has been marked as a duplicate of this bug. ***
I still see this problem on Firefox 2.0.0.2
Ever confirmed: true

    
    

    
  
reclassifying severity based on comments and dupes
Severity: major → normal
Keywords: dataloss
Summary: while loading a page, on a new tab/window, the location bar does not display the address → while loading a page, on a new tab/window, the location bar does not display the address URL

    
    

    
  
this bug was reported in 2004 and is truly becoming a nuisance, why are we unable to press the reload button or see the url the moment a new tab is initialized, i cannot imagine that it is that difficult to populate an address field. is there some reason for a 4 year delay?

    
  
Component: Location Bar and Autocomplete → Document Navigation
Product: Firefox → Core
QA Contact: location.bar → docshell

    
    

    
  
Dao, what exactly do you expect docshell to be doing here?  This seems like a straight-up UI issue, no?

    
    

    
  
It doesn't seem like the UI is aware of the address early enough. When the user clicks on a link with target=_blank, onLocationChange gets called with an empty URI (for the new tab); we get the real URI later when the request has started.

    
    

    
  
Well, onLocationChange comes when the location.... actually changes.  So presumably you want another notification to be added?  When should it happen?  Where should it be sent?  How should HTTP redirects be handled?

And honestly, is this all even an issue, given that if the whole thing fails the error page will show the URI we tried to load?

Finally, what should happen when a page does:

  window.open().location = "something";

How should this differ, if at all, from:

  window.open("something");

Note that these are all UI questions.

Also note that in the window.open() case (but not in the link with _blank target case, sadly) the function that creates the tab knows the UI we plan to start loading in it....

    
    

    
  
(In reply to comment #68)
> Well, onLocationChange comes when the location.... actually changes.  So
> presumably you want another notification to be added?  When should it happen?

Right after the tab has been added.

> Where should it be sent?

nsIWebProgressListener2?

> How should HTTP redirects be handled?

We'd update the location bar based on what onLocationChange tells us. Instead of replacing an empty string, we'd replace the original URI.

> And honestly, is this all even an issue, given that if the whole thing fails
> the error page will show the URI we tried to load?

It's not a big deal, it's just slightly annoying and unexpected behaviour. Users don't know that an empty location bar means that the browser is waiting for a response, they just assume that the browser UI is lagging.

> Finally, what should happen when a page does:
> 
>   window.open().location = "something";
> 
> How should this differ, if at all, from:
> 
>   window.open("something");

I don't think it should differ. In both cases I would assume to see "something" in the location bar while the browser tries to load it.

> Also note that in the window.open() case (but not in the link with _blank
> target case, sadly) the function that creates the tab knows the UI we plan to
> start loading in it....

Yes, the same is true for URIs we get from external apps. But it seems odd to fix these cases separately.

    
    

    
  
> Right after the tab has been added.

Uh...  You're the one doing the tab adding.  All the back end knows is that it's got some docshell and it's doing a load.  Do you want to be notified in all cases when that happens?  What do you plan to do with the result?  How is this different from the existing onStateChange notifications sent to nsIWebProgressListener?

    
    

    
  
(In reply to comment #70)
> Uh...  You're the one doing the tab adding.  All the back end knows is that
> it's got some docshell and it's doing a load.  Do you want to be notified in
> all cases when that happens?

Could it could be limited to when about:blank is loaded?

> What do you plan to do with the result?

Update the location bar if it's empty.

> How is
> this different from the existing onStateChange notifications sent to
> nsIWebProgressListener?

onStateChange doesn't give us the URI.

    
    

    
  
> Could it could be limited to when about:blank is loaded?

That's probably just as easy to do on your end, for what it's worth, but in any case see below.

> Update the location bar if it's empty.

So you're checking for the about:blank thing anyway, basically....

> onStateChange doesn't give us the URI.

It gives you the nsIRequest, which you can QI to nsIChannel and get the URI.

Back to Firefox, since as far as I can tell the back end sends all the notifications you need to make this work...
Component: Document Navigation → Location Bar and Autocomplete
Product: Core → Firefox
QA Contact: docshell → location.bar

    
    

    
  

      
      
      
      

        Attached patch
          
          
        WIP (obsolete)
        — 
          — Splinter Review
      

    


  
d'oh!
Assignee: nobody → dao

        Attachment #204896 -
        Attachment is obsolete: true

        Attachment #204969 -
        Attachment is obsolete: true
Status: NEW → ASSIGNED

    
    

    
  
As the one reporting this bug 4 years ago, I have to say I'm really excited to see it finally being fixed :-)

What I wanted to say (which is kind of a response to comments 68 and 69 above) is this is more than slightly annoying. I'll give you a test scenario:
I'm using a laptop at work, which I also take home with me. At work I use a proxy server to access the web. I have a few tabs open, close the browser and save the session. Firefox is still configured to use a proxy server.
At home I'll open Firefox again and it will try to reload the tabs. But I don't have the proxy server there, so all I see is "connecting to example.com..." in all tabs. No URLs in the address bar. If I cancel, I lose the URLs. I can now disable the proxy, but refreshing the tabs won't help me.
All I can do is wait for the timeout. Only then I'll have the URLs in the address bars.

    
  
Blocks: 439675

    
    

    
  
In addition to the problem Noam described, there are quite a few more:

* In general, pressing cancel while loading loses the URL.
* If you quit Firefox while such a new tab is loading, the restored session will have a blank tab => again, URL is lost.
* The user needs to wait for a server response (potentially long) before they can see or copy/paste the URL.
* If you open several tabs at once, you can't Ctrl+Tab to the right one until the relevant servers have responded because all the tabs look identical.
* In the case of a HTTP redirect, there is no chance to see or copy/paste the URL at all. You will only ever see the new URL (the redirection target).
* If the URL is a file download rather than a page display, the location bar stays empty (or at the page's URL). Again it is impossible to see or copy/paste the URL. Even if you have Download Statusbar installed, which lets you right-click and "Copy source URL" for a running download, you still have to wait for the server response.

I guess what I'm really saying is: Fixing this little thing would solve quite a lot of frustration :)

    
    

    
  
(In reply to comment #73)
> patch
> d'oh!

Does this patch solve the problems described in comment #75?

    
  

        Attachment #337587 -
        Attachment description: patch → WIP

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #337587 -
        Attachment is obsolete: true

        Attachment #337640 -
        Flags: review?(gavin.sharp)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch
        — 
          — Splinter Review
      

    


  
valid = value && (!aURI || aValid);

instead of:
valid = !!value && (aURI ? !!aValid : true);

        Attachment #337640 -
        Attachment is obsolete: true

        Attachment #337642 -
        Flags: review?(gavin.sharp)

        Attachment #337640 -
        Flags: review?(gavin.sharp)

    
    

    
  
(In reply to comment #76)
> Does this patch solve the problems described in comment #75?

It should solve most of them. It probably doesn't change how session restore deals with tabs that are loading while you close them.

    
    

    
  
Don't worry about fixing *all* of those issues, especially if some of them relate to separate modules (like session restore). I'll file separate bugs for those if they persist in 3.1 or 4.0, whichever is the next version.

        Attachment #337642 -
        Flags: review?(gavin.sharp) → review+

    
    

    
  
http://hg.mozilla.org/mozilla-central/rev/7406fe593f84
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1b1

    
    

    
  
After opening a link from an external application, if you click on a tab which has already loaded a page and then click back to check the loading tab, it is blank.

1. navigate to www.google.com
2. open a slow-loading page from an external application
3. check the first tab: www.google.com
4. go back to the slow-loading-page tab

#4: The location bar is now blank for this tab, if it is still attempting to load the page.

    
    

    
  
I don't know what did you fix but the problem is there even when you open a new tab and the page is about:blank the address bar is empty , the same with programs that you are downloading it will show the attachment and the address will be empty,it will be fixed in the future ?


Thanks

    
    

    
  
(In reply to comment #87)
> I don't know what did you fix but the problem is there even when you open a new
> tab and the page is about:blank the address bar is empty , the same with
> programs that you are downloading it will show the attachment and the address
> will be empty,it will be fixed in the future ?
> 
> 
> Thanks i mean with firefox 3.0.0.10

    
    

    
  
When typing "v" in Google Reader to view the original item, the new tab first opens as about:blank. It seems like a reincarnation of this (now closed) bug.

Unless of course, if Reader is doing some funky JavaScript stuff, in which case there's nothing Firefox can do to prevent this from happening. 

Any idea? Should this bug be reopened?

    
    

    
  
(In reply to comment #89)
> Any idea? Should this bug be reopened?

No, but a new bug could be filed, ideally with a reduced test case...

    
    

    
  
(In reply to comment #89)
> When typing "v" in Google Reader to view the original item, the new tab first
> opens as about:blank. It seems like a reincarnation of this (now closed) bug.
> 
> Unless of course, if Reader is doing some funky JavaScript stuff, in which case
> there's nothing Firefox can do to prevent this from happening. 
> 
> Any idea? Should this bug be reopened?

(In reply to comment #90)
> (In reply to comment #89)
> > Any idea? Should this bug be reopened?
> 
> No, but a new bug could be filed, ideally with a reduced test case...

Was a new bug ever opened on this?

    
    

    
  
This now happens again in v4.
My scenario (one of many): 
Start Firefox on a network that requires proxy for http access. Have the proxy turned off. Click an external link in another application (where Firefox is the default browser).  
A new tab opens and Firefox is trying to load the page. However, at this point the address bar is empty, so (1) if you stop trying to load, you lose the address; (2) if you enable the proxy, you can't reload - because the address bar is empty.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
(In reply to comment #92)
Please do never open Resolved Fixed Bugs.
Rather open a new Report describing your Issue in Detail as Comment 90 suggests.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 13 years ago
Resolution: --- → FIXED

    
    

    
  
I think this is a good example of how free software projects often fail to receive bug reports well.  In this case, Noam has explained succinctly how to reproduce the problem.  And rather than creating a duplicate report, he used an existing report--something few reporters do.  But, rather than acting upon the report and fixing the bug, the project instructs him to re-report and re-explain the problem, or else no action will be taken to fix the bug.  That would be a waste of his time--he's already done it.  It's basically insulting to the reporter, implying that his time is of little value.  In this case, either the bug should be fixed within the existing report, or the project developers should take responsibility for the bug and make a new report themselves.  After all, isn't it the project's job to fix bugs once they've been reported?

People who take the time to clearly report bugs are a tiny fraction of a percent of the userbase.  Making them jump through hoops repeatedly will quickly dissuade them from reporting any more bugs.  The bar for reporting bugs should be low, and responsible people within the project should take it from there.

This kind of problem is especially prevalent in large projects, such as Mozilla, because, often, the people going through bug reports are not the same people who fix the bugs.  Policy wonks tend to try to solve the problem of bug reports not being "in order," rather than solving the problem of bugs being in the software.  Their "project" is the bug tracker itself.

In the end, both the end-user/reporter and the project itself suffer: the end user doesn't get his bug fixed, and the project loses a valuable contributor.

    
    

    
  
(In reply to comment #94)
> I think this is a good example of how free software projects often fail to
> receive bug reports well.  In this case, Noam has explained succinctly how to
> reproduce the problem.

I couldn't reproduce the problem with those steps. They belong in a separate bug report anyway, as this one was successfully closed more than two years ago. This is how we keep track of things. I'm sorry that this disturbs you.

    
    

    
  
(In reply to comment #95)
> I couldn't reproduce the problem with those steps. They belong in a separate
> bug report anyway, as this one was successfully closed more than two years ago.
> This is how we keep track of things. I'm sorry that this disturbs you.

(In reply to comment #93)
> (In reply to comment #92)
> Please do never open Resolved Fixed Bugs.
> Rather open a new Report describing your Issue in Detail as Comment 90
> suggests.

If you don't want closed bugs re-opened disable that in Bugzilla.

    
    

    
  
> This is how we keep track of things. I'm sorry that this disturbs you.

While I can't speak for Adam, I didn't get the impression that what disturbs him is how you keep track of things. Perhaps you misunderstood what Adam was saying.

    
    

    
  
Roman is right: I don't necessarily see a problem with opening a new bug for this.  What I think is a problem is that the reporter--who did nothing wrong--is told to open the new report himself, implying that the bug will not be fixed, otherwise.  The onus is placed on the reporter, who has already done his job--he's asked to do it all over again.

If the reporter has a valid report--and since bugzilla allowed him to reopen the bug, his report ought to be considered valid--the project members should take responsibility from that point, including opening a new bug report, if that's what they want done.

Making contributors--including reliable bug reporters--jump through unnecessary hoops, repeating work and wasting their time, will discourage them from contributing further.

I have always been impressed with how Debian handles bug reports.  If a bug needs reorganizing, the package maintainer (or whoever is going through the bugs) does it himself.  I've never seen a user/reporter asked to refile a bug after he's already reported one.  The project takes responsibility itself.  I think that's how it should be done.  To do otherwise almost seems like sticking one's head in the sand until the other guy has done it "just right."

    
    

    
  
No more rants in this bug please. I already said that I couldn't reproduce what's been reported in comment 92. I'm not in the position to transform that into a useful bug report.

    
    

    
  
Noam, ping? I feel responsible for this code and really don't want a valid report to get lost. Do you still see the issue? Do you see it in safe mode <http://support.mozilla.com/en-US/kb/Safe+Mode>? If so, please do file a new bug, so we can track it in an organized manner and eventually fix it. You mentioned there would be many scenarios in which this bug manifested itself -- listing a few of them will increase the chance that someone can confirm your report.

    
    

    
  
Sorry, was really busy with work. 

A test case that I just found:
1. Go to http://twitter.com/firefox. 
2. Find the link to Firefox's website on that page, and look closely at the address bar while clicking it. 

For a second or two (depending on network latency etc) you'll see "about:blank". Later it changes to the correct URL, but if you either cancel the request or just can't connect right now, you lose the target URL.

This happens with Firefox 4.0 on both Mac and Windows.

And yes, it does happen in safe mode.

If it's really important to you I don't mind pasting the above to a new bug report; however I see it as an incarnation of this bug.

(In reply to comment #100)

    
    

    
  
(In reply to comment #101)
> 1. Go to http://twitter.com/firefox. 
> 2. Find the link to Firefox's website on that page, and look closely at the
> address bar while clicking it. 

Reproduced and filed as bug 650631.

    
    

    
  
WinXP SP3 32 Bit

Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110421 Firefox/6.0a1 ID:20110421030547

Bug: verified fixed
Status: RESOLVED → VERIFIED
Whiteboard: [testday-20110422]

    
    

    
  
I can still reproduce this, so I filed bug 689597.

    
    

    
  
FWIW, after seeing comment 100 about Safe Mode, I tried disabling some add-ons and found that the first one I tried did the trick:  Status-4-Evar.  I didn't poke any further to see if any others might be involved as well, but disabling just that one allowed the location bar to load, and reenabling it brought back the empty location bar.

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: