34414 - Editor: View page source renders page instead of displaying source

Status: RESOLVED INVALID

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

Description

[Bernd Mielke]

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

Comment 1

[rubydoo123]

assigning to Charlie. This is a regression.

I was able to reproduce this using the 4 APR build on win95

Comment 2

[Charles Manske]

Akkana fixed this - I'll let her close it.

Comment 3

[Akkana Peck]

I have the change in my tree.

Comment 4

[Akkana Peck]

The fix has finally been checked in (yesterday).

Comment 5

[Blake Ross]

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...

Comment 6

[timeless]

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.

Comment 7

[timeless]

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.

Comment 8

[Jay Patel [:jay]]

Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2. 

Comment 9

[Akkana Peck]

Charley, can you take a look at this?  I haven't checked in anything remotely
related to this in a long time.

Comment 10

[Charles Manske]

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).

Comment 11

[leger]

Moving from [nsbeta2+] to [nsbeta2-] per todays PDT XP Toolkit Beta2 Review mtg.

Comment 12

[Peter Trudelle]

So, what defect remains of this morphed bug?  Do we even need to fix it in the
current release?

Comment 13

[timeless]

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.

Comment 14

[Peter Trudelle]

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.

Comment 15

[Bernd Mielke]

WFM win98 20001001

Comment 16

[Peter Trudelle]

rtm-

Comment 17

[Bernd]

this works perfectly for me win98 2001101308

Comment 18

[sujay]

marking verified per comments

Comment 19

[Mike Lee]

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.

Comment 20

[Mike Lee]

Continuing to bug 125162 for the view problem with editor

Comment 21

[Thomas Bertels]

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.

Comment 22

[Emil Pasca [:emilpasca]]

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).

Comment 23

[Bernd]

FF does not have an editor