I am not sure if this is a bug in Necko or not, but it is a problem in the current build. When you select an item in the combo box, JS script assigns a newly constructed url. For example: var d = "encyclopedia/" + (s.options[s.selectedIndex].value) + ".html"; window.top.location.href = d; Which then ends up in nsLocation.cpp that construct a new URL using NS_NewURL It is suppose to take the current location: www.pokemon.com/pokedex and append: encyclopedia/cloyster.html to form: www.pokemon.com/pokedex/encyclopedia/cloyster.html But for some reason the pokedex part gets truncated off and it constructs: www.pokemon.com/encyclopedia/cloyster.html

Works fine with Necko.

There seems to be a problem with the trailing slash. If you put in http://www.pokemon.com/pokedex/ it works ok, if you put in http://www.pokemon.com/pokedex it does not. Gagan, to reproduce with 7/31, go to http://www.pokemon.com/pokedex then select the drop-down menu and something like 'Bellsprout'. Then, there is some combobox bug that you have to click once more on the combo box. The 'pokedex' part of the URL gets thrown out.

This is also redirects related.

Updated summary/assigned to.

Gagan, can you look at this?

I already did once and explained that its redirect related. The redirected URL does not get reflected in the base URL for subsequent requests. And hence the malformed URL that follows. We need to hunt down whoever is responsible on the other end of OnRedirect (or OnStopRequest) who would look at the modified URL and update the location bar correctly. To summarize- any URL of type- http://www.foo.com/bar where bar is a directory MUST be updated on the URL location bar as http://www.foo.com/bar/ for subsequent requests to work correctly.

This is definitly not an URL-parsing problem. As I see it, the problem is, that when a redirect happens there is made a new channel which replaces the old one. The URL of this new channel has the missing /, all is fine, but whoever is making the request is not informed of this change. So OnEndDocumentLoad is called with the old channel and the URL of that Channel is still the unredirected and that url is displayed in the urlbar. I think there are at least two options: 1. Update the old channels URL ... don't like it 2. Implement the nsIHttpEventSink interface for the caller (if possible) and change the current channel with OnRedirect

Also the URI/URL of the webshell has to be changed in case of an redirection since this one is used in nsHTMLContentSink.cpp to build the new URL for the REFRESH-meta-tag.

Yes this is definitely the case, Andreas. Although #2 is the correct way to go. I just have to hunt down who's responsible for making that change.

*** Bug 12912 has been marked as a duplicate of this bug. ***

don: who's responsible for updating the location bar? thx.

Radha ...

The urlbar is now updated in OnStartDocumentLoad() instead of OnendDocumentLoad(). Is it not possible to send in the new channel with the redirected url to OnStartDocumentLoad().

What about implementing the nsIEventSink interface (OnRedirect...) and let it change the urlbar too?

*** Bug 10926 has been marked as a duplicate of this bug. ***

Related to uri loader or nsIEventSinkGetter (what ever it is called right now)

Putting on PDT radar

Is it not enough if I update the urlbar in OnEndDocumentLoad() so that the redirected url will be displayed in it?

The problem here is that there is a new channel created during redirection, but that new channel (with the new URI) is not propagated to whoever is making the request. As a result the channel used on the webshell (or whoever is calling) does not contain the right url and other functions that use it fail afterwards. This is not only an issue about updating the urlbar or not. I still think the only option is to implement EventSink or uriLoader or whatever for nsWebShell and let the channel (and the URI of the Webshell itself) be updated by OnRedirect.

Since this depends on the new uri loader and the new webshell, moving to M13. I won't be here next week to finish it for M12 time frame.

With jevering's permission ... I removed the PDT+ status of this bug since it's now targeted for M13.

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

This seems more like things to be done in necko rather than a simple urlbar update in browser code.

*** Bug 16156 has been marked as a duplicate of this bug. ***

*** Bug 15863 has been marked as a duplicate of this bug. ***

*** Bug 23286 has been marked as a duplicate of this bug. ***

Rick, is this related to the changes you made tonight to add the LOAD_DOCUMENT_URI flag?

The changes I made for bug #23055 should make this easier... I'm not sure if the load attributes are being propagated correctly for redirects... I'll look at it when I get back...

I'm currently working on app (going to use Mozilla as a principal browser) that relies heavily on redirects so this bug is a big showstopper for me. I've been waiting two weeks hoping in M13 it would be fixed but it was just retargeted for M15 and I cannot wait this long. I've spent weeks convincing my clients Mozilla is the way to go and today we're going to switch to Explorer (four letter word of your choice here). I still don't understand how bug of this importance is not dogfood - without redirects one cannot do any sophisticated web app (no sessions etc). Please reconsider M15 target if at all possible.

*** Bug 13143 has been marked as a duplicate of this bug. ***

*** Bug 26204 has been marked as a duplicate of this bug. ***

here's the test case http://bugzilla.mozilla.org/showattachment.cgi?attach_id=2620 Browse to a file and hit submit.

*** Bug 27381 has been marked as a duplicate of this bug. ***

*** Bug 27035 has been marked as a duplicate of this bug. ***

*** Bug 27972 has been marked as a duplicate of this bug. ***

*** Bug 28748 has been marked as a duplicate of this bug. ***

I think the word REFRESH should be in the summary for this bug. Maybe that will make it easier to find the bug in searches and lower the number of duplicates.

*** Bug 29191 has been marked as a duplicate of this bug. ***

*** Bug 28714 has been marked as a duplicate of this bug. ***

I can see onRedirect method on nsIHTTPEventSink. Is it still a bug?

The test URL does no longer work.

Moving what's not done for M15 to M16.

*** Bug 35275 has been marked as a duplicate of this bug. ***

Since the example url of the last dupe of this bug ( bug 35275 ) is working now and the example URL of this bug can no longer be found, I think it's save to assume that this bug is indead fixed.

Bug 27972 which is dup of this one is still not fixed Try URL of bug 27972

verif.