Closed Bug 34414 Opened 24 years ago Closed 8 years ago

Editor: View page source renders page instead of displaying source

Categories

(Core :: DOM: Editor, defect, P3)

x86
Windows 98
defect

Tracking

()

RESOLVED INVALID
Future

People

(Reporter: bernd.mielke, Unassigned)

References

Details

(Keywords: helpwanted, regression, Whiteboard: [nsbeta2-][dogfood-][rtm-])

Open a page in the editor without editing it and select view page source.
I tested it with a debug build from 04.04.2000  on win98
Status: UNCONFIRMED → NEW
Ever confirmed: true
assigning to Charlie. This is a regression.

I was able to reproduce this using the 4 APR build on win95
Assignee: beppe → cmanske
Target Milestone: --- → M15
Status: NEW → ASSIGNED
Target Milestone: M15 → M16
Akkana fixed this - I'll let her close it.
Assignee: cmanske → akkana
Status: ASSIGNED → NEW
I have the change in my tree.
Status: NEW → ASSIGNED
The fix has finally been checked in (yesterday).
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I see this problem in 2000062408 win98. selecting View | HTML Source... after 
opening a page and not modifying it either causes just a blank page to display, 
or the rendered page...no source.  If the page seems blank, scrolling down 
(with the scrollbars) usually causes the rendered page to come into view (some 
kind of redraw/repaint issue).  reopening...
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: FIXED → ---
m16 is gone, the bug has returned, nominating for nsbeta2 and dogfood, I use 
composer to do mozilla testing and bug triaging, it's often very useful to be 
able to use mozilla composer's source editor since i can't copy from 
view-source.
Keywords: dogfood, nsbeta2
Target Milestone: M16 → M17
2000070108win32[faulty]talkback
once you've entered this mode, the other three modes will show no content. 
Returning to this mode will also show no content.
Severity: normal → major
Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2. 
Whiteboard: [nsbeta2+][dogfood-]
Charley, can you take a look at this?  I haven't checked in anything remotely
related to this in a long time.
Assignee: akkana → cmanske
Status: REOPENED → NEW
This bug has mutated a bit: Here's the current problem:
The XUL contains this structure:
<deck>
  <editor/>     // The main editor window
  <textfield/>  // the HTML Source editor
</deck>
The deck frame code "hides" each child by getting its view from the press shell
and setting the size to 0,0. But recent changes in the <editor> tag (probably
by hyatt?) are such that there is no view associated directly with the 
<editor> outermost frame. Thus the deck code fails.
Temporary kludge is to wrap <editor> in a <stack>, which has a view.
I will keep this bug open so hyatt can investigate and make the proper fix,
but I'll check in the temporary <stack> fix so the feature doesn't block other
nsbeta2+ work, such as the chrome enabling/disabling (38875).

Assignee: cmanske → hyatt
Blocks: 38875
Moving from [nsbeta2+] to [nsbeta2-] per todays PDT XP Toolkit Beta2 Review mtg.
Whiteboard: [nsbeta2+][dogfood-] → [nsbeta2-][dogfood-]
So, what defect remains of this morphed bug?  Do we even need to fix it in the
current release?
I'm going to guess we need this for xul purposes before rtm.  Since we're 
working around this, maybe we need a testcase? With the workaround nsbeta2- and 
dogfood- are fine. To answer your question, from what i understand the <deck> 
xul container is still defective.  If someone wants to they could file another 
bug on deck to the correct component (making it block this bug), otherwise we 
probably should change the summary.
Keywords: rtm
Please file other defects in separate bug reports, don't morph this one any
further.  I'm still not seeing anything here that would stop rtm, moving to
Future/helpwanted.  If you think we have to fix for rtm, nominate for nsbeta and
give us a compelling reason why.
Keywords: helpwanted
Target Milestone: M17 → Future
WFM win98 20001001
Whiteboard: [nsbeta2-][dogfood-] → [nsbeta2-][dogfood-][rtm-]
rtm-
Keywords: nsdogfood-
Keywords: nsdogfood
this works perfectly for me win98 2001101308
Status: NEW → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → WORKSFORME
marking verified per comments
Status: RESOLVED → VERIFIED
What the new bug number the view problem? I don't think one is created, and
editor.xul's hack comment still points to this bug.
Continuing to bug 125162 for the view problem with editor
Please don't forget

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=/mozilla/editor/ui/composer/content&command=DIFF_FRAMESET&file=editor.xul&rev2=1.66&rev1=1.65

This "temporary" fix is still there, which explains why this bug can't be reproduced.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
QA Contact: sujay → editor
Assignee: hyatt → nobody
Mozilla/5.0 (Windows NT 5.1; rv:49.0) Gecko/20100101 Firefox/49.0

I have tested this on Win 10 x64 and Win XP x32, with the latest Firefox release (46.0.1), the latest Nightly(49.0a1-20160601061753) and also with the an older version of Firefox(0.10) and I was unable to reproduce it. After opening a webpage in the browser and using the shortcut key CTRL+U to view source, the source code had rendered correctly.

Can you please retest this using the latest Firefox release and the latest Nightly build (https://nightly.mozilla.org/) and report back the results? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E).
Flags: needinfo?(bernd.mielke)
FF does not have an editor
Status: REOPENED → RESOLVED
Closed: 23 years ago8 years ago
Resolution: --- → INVALID
Flags: needinfo?(bernd.mielke)
You need to log in before you can comment on or make changes to this bug.