Closed
Bug 171791
Opened 22 years ago
Closed 22 years ago
Browser frame behavior on all pages breaks when home page default is set to other than default
Categories
(SeaMonkey :: General, defect)
SeaMonkey
General
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: chris, Assigned: asa)
Details
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•22 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•22 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
Closed: 22 years ago
Resolution: --- → WORKSFORME
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•