140959 - Browse button does not work after using it second time

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[michael wendell]

If you publish via FTP without filling in the "HTTP address to browse to:"
field, and then click on the Browse button, you will see an about:blank page.

Steps to reproduce:
1. Launch Composer
2. Type some text
3. Publish the page via FTP without filling in the "HTTP address to browse to:"
field.
4. Click on the Browse button on the toolbar.

Actual results:
Blank page displayed, with about:blank in the URL bar.

Expected results:
I would expect that the page I just created would be published.

Reproduced on the 04-29 trunk.  04-28 1.0.0 branch appears to be working fine.

Comment 1

[Charles Manske]

I can't reproduce this. I'm wondering if the page actually published correctly.
Where are you publishing to?
What is the url of the page after you publish? After publishing, look in "Format,
Page Title and Properties" to view the url.

Comment 2

[michael wendell]

Yes, the page is publishing fine.  If I go into the browser, and manually
navigate to the page, it is there.

The URL of the page after publish is
ftp://[e-mail]/sites/index.html.  Which is exactly what I
would expect it to be.  

Comment 3

[Charles Manske]

When you published, was your password saved in Password Manager (checkbox was 
checked in Publish dialog and you supplied password there)?
Whatever you did before for password, try the opposite. E.g., if you supplied it,
don't now and uncheck the "Save..." checkbox.

Comment 4

[michael wendell]

I am seeing this problem whether I save the password or not.  

When I save the password, the FTP url flashes in the URL bar briefly before
about:blank is displayed.

When I do not save the password, the FTP url flashes briefly in the URL bar,
then about:blank is displayed, and finally the password box comes up asking me
for the password.  When I enter the password, the page does not change to the
actual page, and about:blank is still displayed.

Comment 5

[Charles Manske]

Ahhh! Now I'm seeing this bug. The very first time I used "Browser" after 
starting Composer and publishing a page, the Browse command works.
But if I make further changes to page, then used it, I see the url appear very
briefly in Browser's URL input field, but then it changes to "about:blank:"
In debug output window, I see this error:
"Error loading URL ftp://[e-mail]/test.html : 804b0002"
This was working fine not too long ago.

Comment 6

[michael wendell]

Looks to me as though this was first broken on the 04-28 trunk build.  The 04-27
trunk build appears to me to be working.

Hope this helps.

Comment 7

[Charles Manske]

So to test, be sure to 
1. publish once
2. Use Browse button to load into Browser.
3. Close that browser window.
4. Use Browse button again.

Comment 8

[Charles Manske]

Attachment: patch v1

Fix is to not try to reload URL with "bypass cache" flags after we just 
created a new browser window with the URL to preview. The problem only occurs
in that case; maybe the cause is some timing issue because we are trying to 
reload the url before initial load is finished?
While this problem was probably caused by a recent checkin, this fix makes 
sense for these reasons:
1. You must have saved or published the document from Composer before you are
allowed to preview contents in browser, thus when you create a new browser
with that url, it always gets the newest version of the page. I tested this
with cache pref settings set to both "Every Time" and "Never". Thus there's 
no need to try to reload the url again.
2. All cases when you find an existing browser with the url we are editing are
still found and the BrowserReloadSkipCache() still works fine for reloading 
the page to show newly edited content.

Comment 9

[Charles Manske]

CC'ing Darin and Adam: Do you know any recent checkins that might make
BrowserReloadSkipCache() fail if browser window is in the process of loading
that URL? That behavior doesn't sound bad, but it was the cause of this bug so I
just curious why that behavior changed.

Comment 10

[Darin Fisher]

does this bug also occur on the branch?

Comment 11

[michael wendell]

I am not seeing this problem on the 04-30 1.0.0 branch.

Comment 12

[Charles Manske]

Attachment: patch v2

If we don't need to reload the url after creating a new browser window,
then we don't need the "setTimer" delay when calling BrowserReloadSkipCache()
when the window already exists.

Comment 13

[Darin Fisher]

cmanske: i have no idea what might explain this change in behavior.

Comment 14

[Kathleen :Brade]

Comment on attachment 81801 [details] [diff] [review]
patch v2

now that I've seen more context I understand this fix better; I think it's the
right thing to do.  r=brade

Comment 15

[kinmoz]

Comment on attachment 81801 [details] [diff] [review]
patch v2

sr=[e-mail]

Comment 16

[Charles Manske]

checked into trunk
ComposerCommands.js:
new revision: 1.123; previous revision: 1.122

Comment 17

[michael wendell]

Verified on the 05-06 trunk build.

Comment 18

[michael wendell]

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

Comment 19

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) for approval to checkin to the 1.0 branch, pending
Drivers approval.  After, checking in, please add the fixed1.0 keyword.

Comment 20

[chris hofmann]

a=chofmann for 1.0.1

Comment 21

[Charles Manske]

checked into mozilla1.0.1 branch

Comment 22

[sujay]

verified in 6/4 branch build.