46331 - urls dispatched to helper apps are getting added to session history....

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P2)

Description

[Scott MacGregor]

Load a page like broadcast.com. Click on one of the audio links on the page.
Notice that we dispatch the url to a helper app because mozilla can't handle the
content internally.

Everything looks great. If I try to hit reload, we try to reload the helper app
url instead of the actual document url currently loaded in docshell. In
addition, if I hit back, we again try to lad the helper app url instead of the
previous document we loaded.

Looks like we are incorrectly adding urls that don't result in a document
actually being loaded to session history. So urls that get farmed out to helper
applications are added.

I'll try to investigate this for beta3.

Comment 1

[Scott MacGregor]

adding appropriate beta3 keywords

Comment 2

[Radha on family leave (not reading bugmail)]

We have similar problems with ftp download dialogs and JS alert dialogs. 

Comment 3

[Scott MacGregor]

adding beta3+ after triage mtg.

Comment 4

[Scott MacGregor]

This is now fixed. To test, go to a site like www.broadast.com and click on a
link that brings up winamp. If you later go back to the browser window that
launched this helper app, goto another link then hit back, you would have
reloaded the helper app url. Now, we don't do this. 

Comment 5

[Doron Rosenberg (IBM)]

Do I understand correctly: clicking a 2nd item should load in the originally
opened player, not the app again? If yes, this is verified.