Closed Bug 96745 Opened 24 years ago Closed 24 years ago

Specific site does not spawn nor display in new Composer window

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED INVALID

People

(Reporter: TucsonTester1, Assigned: Brade)

Details

(Whiteboard: test case needed)

Attachments

(1 file)

Test case of a blank .html page with meta-redirects in the header
312 bytes, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.3+) Gecko/20010821 Netscape6/6.1b1 BuildID: 20010821 Attempting to open a specific site <http://www.azstarnet.com/public/dnews> in Composer does not spawn a new Composer window, nor is the site displayed in the current Composer window. Also a little of the page`s HTML is inserted and appears in Composer`s <HTML> Source tab, however the document cannot be immediately saved because none of the following are available or working: the [Save] button on the Toolbar and the the File | Save menu option (both are greyed-out); and the Save hotkey (keyboard-shourcut) <CTRL>+<S> does nothing. Clicking back and forth a few times on the tabs at the bottom seem to bring the Save options available. The page changes daily (a news site), so I do not know whether this behaviour can be examined after today. Reproducible: Always Steps to Reproduce: (1) From the Desktop, launch a Navigator window and allow the software and the default page to load (2) Launch a Composer window to start editing a document (3) Go File | Open Web Location... (or use <CTRL>+ <SHIFT>+<L>) to open the Open Web Location dialogue (4) Enter the URL: <http://www.azstarnet.com/public/dnews> (5) Select `New Composer window' for Open in: pull- down menu option (6) Click [OK] or press <enter> Actual Results: The new Composer window does not spawn. The current Composer window remains and appears to be blank, unaffected. The Save methods are inactive or greyed-out. However there is a bit of the attempted page`s HTML now present on the <HTML> Source tab on the bottom of Composer. That turns out to be a meta refresh tag from the site whose contents we just attempted to load into Composer. Expected Results: A new Composer window should spawn, displaying a copy of the site`s contents, ready for editing and saving. The lines of HTML that do appear in the <HTML> Source tab of the original (and only) Composer window: <html> <head http-equiv="Refresh" content="0; URL=http://www.azstarnet.com/star/today"> <meta http-equiv="Refresh" content="0; URL=http://www.azstarnet.com/star/today"> </head> <body> <br> </body> </html>
Can someone come up with a testcase for this? Is it the http-equiv="refresh" that is causing the problem or ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows ME → All
Hardware: PC → All
After reviewing this matter another couple of additional times I see that this is going to be a tough nut to crack. The page causing Composer`s reported behaviour is a news site, so it is changed daily. Yesterday (27 August 2001, Monday) Composer did not express the same behaviour as I previously reported. Instead it was able to load the page properly and allowed editing and saving. This morning, however it has returned to expressing Thursday`s reported behaviour. As an experiment I reviewed the HTML source for the page, both after loading it in Navigator from its server, and from a local saved copy, in Navigator and Composer. What I have found is that I cannot locate a ``refresh'' tag in either the page originating from the server, nor from a saved-file version of the same page`s information. It is difficult to tell from where the refresh tag I cite in Thursday`s report originates. Another note: Opening the page locally I was no longer able to get the Composer to behave the way it does when attempting to open and edit the page from its server. It appears that if the page is saved and edited locally Composer is able to load and edit it, _sans_ a few of its graphics. I apologise that I cannot provide more, additional clues than these.
spam composer change
Component: Editor: Core → Editor: Composer
Sujay, Shrir--can one of you come up with a testcase for this and put it on an internal server? (at least then it wouldn't change)
Whiteboard: test case needed
I don't think this is a bug, and here is why: The Page that he is referring to (http://www.azstarnet.com/public/dnews) is a blank webpage with two meta-refresh tags in it pointing to other areas on the site. If you were to look at this page in a browser it would appear as a blank window (albeit very briefly before redirecting). By going to file -> open web location he is expecting to see the page this redirects to being opened as editable in composer. Instead what happens is the actual redirect page is opened as editable in Composer - but gives the impression of a blank page (since there is nothing between the <BODY></BODY> tags. If I complete the steps to reproduce I get a blank page in composer - but the source reveals that it actually has the meta refresh tags and is the correct page. I will attach a copy of the page as I saved it today. If anything I think this might be a feature request for some sort of messaging when composer opens a page with meta-redirects in it, otherwise it may be invalid? NOTE: I tested this on another page with a meta-redirect (http://unhealthy.com/) and it works just fine. unhealthy.com is one of those fake 404 type pages.
Thanks for the investigation on this bug! Resolving this bug as invalid due to redirects in browser. Composer is doing the right thing by editing this document without the redirects.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
v
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: