Browser frame behavior on all pages breaks when home page default is set to other than default

VERIFIED WORKSFORME

Status

VERIFIED WORKSFORME
16 years ago
14 years ago

People

(Reporter: chris, Assigned: asa)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826

I have noticed that in my setups at home and at work, new installs of Mozilla
seem to work with a frames-based interface to a popular open-source content
management platform (Zope) However, the behavior changed as to make the CMS
management interface unusable after the installation had been used a bit. I have
traced the changing in behavior down to the line in prefs.js that indicates
Mozilla's default home page. For example, on Mac OSX, the line in the Chimera prefs 

"user_pref("browser.startup.homepage", "http://www.mozilla.org");" 

allows me to use the frames-based management interface properly. 
However, when I changed this line to 

user_pref("browser.startup.homepage",
"http://www.msri.org/people/staff/cbeaumon/NewLinkPage/newlinks.html");

The bahavior became such that when I brought up the Zope management interface,
the right frame brought up the index.html file for that directory, rather than
the desired bahavior, which would have been to bring up the page specified in
the user interface. 

This may have something to do with *authentication*, but it is a quirk unique to
Mozilla-based browsers..

Here is the source of the page...

manage_main is the page which should come up in the right frame, instead,
index.html comes up. 

*when I replace the line in prefs.js with the original text, the behavior
reverts to the desired behavior.*

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en">
<head>
<title>zeta.msri.org on http://zeta.msri.org</title>
<script LANGUAGE="javascript">
<!--
function update_menu()
{   window.manage_menu.location.href=window.manage_menu.location.href;
}
//-->
</SCRIPT>
</head>
<frameset COLS="175,*">
  <frame SRC="http://zeta.msri.org/manage_menu" NAME="manage_menu"
   MARGINWIDTH="2" MARGINHEIGHT="2" SCROLLING="auto">
  <frame SRC="http://zeta.msri.org/manage_workspace" NAME="manage_main"
   MARGINWIDTH="2" MARGINHEIGHT="0" SCROLLING="auto">
</frameset>
<noframes>
Management interfaces require the use of a <b>frames-capable</b> web browser.

</noframes>
</html>


Reproducible: Always

Steps to Reproduce:
1.see above
2.
3.

Actual Results:  
was able to reproduce the problem and then eliminate it by either telling
Mozilla to use the default home page in prefs, or by editing prefs.js file.

Problem does not manifest itself until the next restart after the prefs have
been changed..

Phoenix appears not to manifest this bug...so far...

Comment 1

16 years ago
reporter (Chris): can you reproduce this bug with a recent build of mozilla (for
example, 1.2.1)? if so, please comment again with details. if not, please
resolve this bug as WORKSFORME. thanks.

Comment 2

16 years ago
Resolving due to lack of response from reporter.

Please reopen if this bug appears in a new build of Mozilla.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 3

16 years ago
verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.