Closed Bug 41090 Opened 24 years ago Closed 24 years ago

[regression] View source shows blank page

Categories

(SeaMonkey :: UI Design, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: teruko, Assigned: law)

References

Details

(Keywords: regression, relnote, Whiteboard: [nsbeta2+][dogfood-])

Page source page does not contain anything.

Steps of regression
1. Go to http://home.netscape.com/
2. Select View|Page Source
 
   Page source page does not contain anything.

Tested 2000-05-31-08 Linux and Win32 build.  This did not happen in 2000-05-30 
builds.
Nominating for dogfood.
Keywords: dogfood
this is probably a dup of 41088, asking sfraser if that is a true statement
No, unrelated to 41088 (unless there is a very generic window opening problem). 
View Source is a browser issue.
Assignee: asadotzler → law
*** Bug 41091 has been marked as a duplicate of this bug. ***
changing QA contact to sairuh, component to xpapps
Component: Browser-General → XPApps
Keywords: regression
QA Contact: jelwell → sairuh
bug 32437 and bug 32142 are the same thing, but they're old and this is a 
regression, so highly unlikely that they're related
removing dogfood status, but setting nsbeta2+.
Keywords: dogfood
Whiteboard: beta2+
changing to nsbeta2+ so this shows up on radar
Keywords: nsbeta2
Whiteboard: beta2+ → nsbeta2+
M18 ...
Priority: P3 → P2
Target Milestone: --- → M18
M18, yet nsbeta2+? How does that work?
adding dogfood and relnote kw. okay, i can put up with this not being fixed for
m16, but this is an obvious regression that oughtta be fixed by m17. imho :-)
Severity: normal → critical
Keywords: dogfood, relnote
*** Bug 41227 has been marked as a duplicate of this bug. ***
"View source" is broken.  viewsource.js does 
document.getElementById("content-frame") and expects to get back a object with a  
"docShell" property (which should be an xpconnect wraper for an nsIDocShell 
interface).

As it stands, it gets a "XULElement" (nsIDOMXULElement, I presume) which doesn't 
have any such "docShell" property.

My theory is that XUL <iframe>s are now some sort of XBL-defined widget rather 
than an <iframe>-specific widget like they used to be.  I will have to talk to 
somebody who know smore about how to get this working again.
Status: NEW → ASSIGNED
Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2.
Whiteboard: nsbeta2+ → [nsbeta2+][dogfood-]
I talked to Dave Hyatt and we've got past the first hurdle.  There was a typo in 
the xbl for the iframe and the docShell property was broken.  We fixed that and 
then started getting assertions from the bowels of the doc shell (I think it 
was).  I'm investigating that now (or will be, depending on what else is going 
on).
fwiw, View Source is now working for me in 60308 win me.
View source working with 60308 in Windows 98
View source is also working with 60308 on Red Hat 6.2
Yes, Dave Hyatt's fix should get it working in release builds (where the 
assertion is compiled out).  I still need to either resolve or remove the 
assertion that pops up in debug builds, I think.

We can probably downgrade this now, though.
Severity: critical → normal
Resolving this fixed.  The assertion seems to have gone away for now and "view 
page source" works AOK.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
a-yup. vrfy 2000.06.14.08-m17 all/all.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.