Closed Bug 71822 Opened 24 years ago Closed 24 years ago

Can not view page source code

Categories

(SeaMonkey :: UI Design, defect)

x86
All
defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: tracy, Assigned: paulkchen)

Details

(Keywords: smoketest)

Attachments

(1 file)

seen on linux commercial build 2001-03-13-05-mtrunk -browse a page -attempt to view page source with View | Page Source a new window is not opened with the source code as expected.
Keywords: smoketest
reassigning
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Also broken on mozilla builds. Console: JavaScript error: chrome://navigator/content/navigator.js line 1018: focusedWindow has no properties
View source worked OK on a linux CVS build w/changes up through 03/13/2001 00:39
R.K.Aa, thanks, appreciate the info.
Blocks: 71173
Just tested mac build 2001031309, and view source works. Interesting...
No longer blocks: 71173
Also, there is no js warning at navigator.js, line 1018 on the mac.
I pulled this morning, and I see the same JS warning (and view source not working) on NT. Happens with both keyboard shortcut and menus. Changing OS to all. I found a workaround: type "javascript:1" + ENTER in the URL bar. After that View Source works normally.
OS: Linux → Windows NT
AO=All for real...
OS: Windows NT → All
Attached patch can't we just do this for now? (deleted) — Splinter Review
Well, only the edit to navigator.js ;-) Ok, though it's kinda funny, but patch=alecf, r=pchen
Yeah, not sure what the <offline-indicator stuff is, but if a XUL tag isn't properly set up with a display type or XBL binding etc, you get warnings about unknown frame type. a=ben for the navigator.js part.
seeing this also on Mac 2001-03-13-10-trunk was able to view page source at first, but once I tried to view an international page this became broken. (at least that seems to be what broke it)
Alec has checked in the workaround. Marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Um, isn't the fix wrong? You've now scoped the declaration of docCharset so that what you will pass into openDialog will always be undefined! If you see it working it is perhaps because you are viewing pages where the charset matches our defaults... Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
no! javascript has function-scoped variables... it doesn't matter if it's declared in the if
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Doh... one of these days I should read a JS book I guess...
vrfy fixed using 2001.03.21.08 comm bits on the 3 main platforms.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: