Closed Bug 838892 Opened 11 years ago Closed 11 years ago

View Selection Source Does Not Reflect View Page Source

Categories

(Toolkit :: View Source, defect)

Product:
Toolkit
Component:
View Source
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 164906

People

(Reporter: david, Unassigned)

References

(
URL
)

Details

Attachments

(4 files, 2 obsolete files)

Display seen after Select All and View Selection Source
11.25 KB, text/plain
Details
[View > Page Source] from menu bar
11.20 KB, text/plain
Details
RSS feed.xml file
3.38 KB, application/xml
Details
View Selection Source of feed.xml
10.46 KB, text/plain
Details 
Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 SeaMonkey/2.15.2

I encountered this problem when I needed the source HTML from a small fragment of one of my Web pages for use in another HTML file.  I selected about three lines from the rendered page and then requested View Selection Source.  What I saw disturbed me because I wondered "When did I create such tag soup?"  It turned out that the tag soup was generated by View Selection Source and not by me; my actual HTML page did not contain any of that mess.  

In the ViewSelectionSource attachment, note the proliferation of </p> and </li>, which are optional, unnecessary, and not present in the original source (an HTML file).  I wanted to view the actual source fragment, not a prettified version of the source.  

At the minimum, there should be an option to make View Selection Source from the pull-down context menu work the same as [View > Page Source] from the menu bar.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Attached file [View > Page Source] on menu bar (obsolete) — 
This is very much the same as the original source HTML file.  The tag soup seen in ViewSelectionSource.txt are not present.  The <!DOCTYPE> declaration (missing from ViewSelectionSource.txt) is present.  Formatting such as line-breaks and indentations remain unaltered here but eliminated in ViewSelectionSource.txt.  Tags on separate lines in the original source remain on separate lines here but are combined onto single lines in ViewSelectionSource.txt.
Comment on attachment 711050 [details]
Select All, then View Selection Source of cited URI

<html><head>
<title>Please:  ASCII-Formatted E-Mail Only</title>

<meta name="Author" content="David Ross">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

<link rel="alternate" type="application/rss+xml" href="http://www.rossde.com/feed.xml" title="David's Web site has been  updated.">

<link rel="shortcut icon" href="../DR.ICO" type="image/x-icon">   
<link rel="icon" href="../DR.ICO" type="image/x-icon">

<meta name="description" content="Please do not send me E-mail messages that are HTML-formatted."> 

<link rel="STYLESHEET" type="text/css" href="../genl_style.css">
<link rel="STYLESHEET" type="text/css" href="internet.css">
</head>

<body>

<table width="100%"><tbody><tr valign="middle">
<td width="50%"><a class="image" href="../viewing_site.html"><img class="browser" src="../anybrowser.gif" alt="Viewable With ANY Browser" title="link to 'Viewing My Web Pages'"></a>
<p class="nostyle"><b>Note:</b> My Web pages are best viewed with style sheets enabled.  
</p></td>
<td style="text-align: right; width: 50%"><a href="../unrated.html">Unrated</a></td>
</tr></tbody></table>


<h1>ASCII E-Mail Only</h1>
<h3 class="cphd">Copyright <a href="../copyright.html">©</a> 2008-2012 by David E. Ross</h3>

<p class="lead">Please do not send me E-mail messages that are HTML-formatted.  Think!  The information you wish to convey should be expressed in well-written sentences with correct grammar, spelling, punctuation, and syntax.  You do not really need colored, strange fonts.  You do not need bold and Italics.  Does the graphic you wish to embed really provide information?  Or is it merely decoration?  

</p><div class="box">
<h3 class="cphd">Why HTML formatted e-mail is best avoided</h3>
<p>In general, HTML formatted e-mail is a nuisance. Normally, the effect of using HTML is that your message may appear strange or hardly legible at the recipients screen, because different e-mail clients handle HTML differently (and everybody doesn't use Micro$ofts e-mail software). One of the most annoying aspects of HTML messages is that they sometimes include graphics or sounds linked from the web, causing your dial-up networking connection to be activated and your modem to start dialing. There are other ways of irritating the receivers of your e-mail than sending it HTML coded, but few are more efficient.

</p><p>Parting with some of the capabilities of HTML, like the ability to insert animated graphics of smiling faces, might actually be quite beneficial for some. Without them, they may just have to rediscover the art of writing in order to convey their thoughts.

</p><p class="qtsrc">by Jörn Rönnow (used with permission)
</p></div>

<p>There are some very good reasons to avoid HTML-formatted messages:  

</p><ul>
<li>An HTML message is actually about 3-5 times larger than an ASCII message with the same amount of text.  
<ul>
<li>An HTML message takes 3-5 times longer to download than the same information in an ASCII message.   
</li><li>An HTML message takes 3-5 times longer to pass through my anti-virus scanner, even with a broadband connection.  
</li><li>If I keep your HTML message, it occupies 3-5 times as much disc space as the same content in an ASCII message.  
</li><li>Many U.S. corporations must now archive all their E-mail — internal, incoming, and outgoing — because of federal laws enacted as a result of the major corporate frauds that occurred in the beginning of the 21st century.  They want ASCII-formatted messages in order to limit their investment in archiving media.  
<div class="sideright" style="width: 35%">
<p class="nostyle">*** Begin Right Sidebar ***</p>
I researched both "bloat" and HTML errors in HTML-formatted messages.  My results are presented in my <a href="ASCIIvsHTML.html">ASCII vs HTML E-Mail: Sizes and Errors</a>.
<p class="nostyle">*** End Right Sidebar ***</p>
</div>
</li><li>Some E-mail services limit the size of a user's inbox.  When that limit is reached, either further incoming messages are blocked or else the user must pay for additional inbox space.  Because of <a href="ASCIIvsHTML.html">bloat</a>, HTML-formatted messages will more quickly fill an inbox than will ASCII-formatted messages.  
<p>As reported by <a href="http://www.pcpro.co.uk/news/377695/ee-4g-data-caps-that-are-broken-in-5-mins">PC Pro</a>, a British 4G network is now placing a cap of 500&nbsp;MB (Mega bytes) per month for £36 (US$57 at the time this was written).  In my study of "bloat" cited in the box to the right-above, I collected data from only 20 HTML-formatted E-mail messages, which totalled more than 325&nbsp;MB.  That means it would take only 31 such HTML-formatted messages to exceed a month's allowed downloading.  The same content in ASCII-formatted messages required only 96&nbsp;MB, which would then take 105 messages to exceed that limit.  
</p></li><li>Some <a href="intr_gloss.html#ISP" target="glossary" title="term defined in separate Glossary window or tab">ISPs</a> (e.g., AT&amp;T, Comcast) now limit the total bytes a user can download, levying extra charges on bytes beyond the allowed limit or even blocking further downloads.  While bloated HTML-formatted E-mail messages are unlikely to cause a recipient to reach that limit, they will cause problems for recipients who are already near ot at that limit.  
</li><li>Making bloat worse is the capability of some E-mail <a href="intr_gloss.html#client" target="glossary" title="term defined in separate Glossary window or tab">clients</a> that send a message that combines both HTML formatting and ASCII formatting, supposedly in an attempt to satisfy everyone.  Instead of 3-5 times larger, these messages are 4-6 times larger than mere ASCII-formatted messages.  
</li></ul>

</li><li>Many E-mail applications generate invalid HTML that does not comply with the <a href="http://www.w3.org/TR/REC-html40/">W3C HTML specification</a>.  I know.  I have taken HTML-formatted messages and processed them with the <a href="http://validator.w3.org/">W3C HTML validator</a>.  If your E-mail application is different from mine, mine might not be able to display your message properly.  Even if I can display your message, the result may be garbled if I try to quote your message in a reply to you or in a forwarded message to someone else.  

<p>Further, messages formatted in non-compliant HTML generally cannot be "read" by audio E-mail applications used by the blind.  It might be a violation of the Americans with Disabilities Act (ADA) for a business or government agency to send such HTML-formatted messages, resulting in a <a href="Webdevelopers.html#targetstore">costly lawsuit</a>.  

</p></li><li id="mal_images">Contrary to popular belief, much of the added content in an HTML-formatted message — especially graphics and background images — are attachments and not "inline".  Only when the Internet packets arrive at your E-mail application, are images merged back into the HTML.  To protect me from viruses, however, I have set my E-mail application to prevent it from opening or using any attachment.  (Yes, JPEG, GIF, BMP, and PNG image files have been known to contain <a href="http://search.us-cert.gov/search?utf8=%E2%9C%93&amp;input-form=advanced&amp;affiliate=us-cert&amp;query-or=JPEG+GIF+PNG+BMP&amp;per-page=10&amp;filter=off&amp;x=31&amp;y=9">serious malware</a>.)  As a result, your HTML-formatted message displays with "broken image" icons <img src="../broken-image.gif" alt="icon" title="icon for a broken image" height="16" width="14"> instead of your intended images.  

</li><li>Some spam filters treat HTML-formatted messages as more likely to be spam.  Of course, HTML formatting is not the only criterion; but when added to certain words in the message text — words that might be quite innocent — HTML formatting might be enough to make a filter reject your message.  Your message might not reach its intended addressee.  

</li><li>Some Web E-mail applications have options to render all messages in plain text, as if they were ASCII-formatted.  Many users select that option, in which case any effort to create HTML-formatted messages is wasted.  

</li><li>Plain ASCII text cannot contain a computer virus.  An HTML-formatted message, however, can contain scripts that either are viruses themselves or fetch viruses from the Internet.  

</li><li>Reading HTML-formatted E-mail can result in a <a href="http://en.wikipedia.org/wiki/Web_bug">Web bug</a> being downloaded into your computer.  
<blockquote title="quoting the introduction to the Wikipedia article on Web bugs">A web bug is an object that is embedded in a web page or e-mail and is usually invisible to the user but allows checking that a user has viewed the page or e-mail.</blockquote>
A Web bug might thus be considered similar to a computer virus.  At the least, a Web bug violates your privacy.  If the E-mail was <a href="spam.html">spam</a>, the sender will know not only that you actually opened the message but also how often, thus subjecting you to an increased volume of spam.  HTML-formatted E-mail rendered in plain text defeats most (but not necessarily all) Web bugs but — as noted above — also defeats the HTML formatting.  ASCII-formatted E-mail might contain Web bugs as attachments, but those Web bugs are not enabled unless you actually attempt to open the attachments.  

</li></ul>

<p>Most E-mail applications have options to use ASCII-formatting.  Some even have options to use ASCII-formatting automatically for selected addresses.  There is no good reason why you cannot comply with my request.  

</p><p>No, Rönnow and I are not alone in our rejection of HTML formatting for E-mail.  

</p><blockquote style="width: 45%; margin-top: 1em">Plain text is for email; HTML is for web pages
<p class="qtsrc">From someone else's message signature
</p></blockquote>

<p>See also:
</p><div class="cols">
<div class="col-left">
<img class="lft" src="../ASCIIonly.gif" alt="ribbon logo for 'ASCII Only' campaign" height="48" width="48">
</div>
<div class="col-right">
<ul>
<li><a href="http://www.delorie.com/listserv/mime/">Why HTML Mail is Evil</a>
</li><li><a href="http://www.asciiribbon.org/">The ASCII Ribbon Campaign</a>
</li><li><a href="http://www.georgedillon.com/web/html_email_is_evil_still.shtml">HTML e-mail is STILL evil!</a>
</li></ul>
</div>
</div>

<p class="date" style="clear:both">25 August 2008
<br>Updated 23 October 2012

</p><hr> 

<p>
</p><table align="center" width="60%"><tbody><tr>
<td class="footer">
<a class="image" href="index.html"><img class="internet" src="internet.gif" alt="Link to Table of Contents for my Internet pages" title="Link to my 'Internet' Table of Contents"><br>"Internet" Table of Contents</a>
</td>

<td class="footer">
<a class="image" href="../index.html"><img class="home" src="../home.gif" alt="Link to David Ross's home page" title="Link to David Ross's home page"><br>David Ross home</a>
</td>

<td class="footer">
<a class="image" href="../mail_to_me.html"><img class="mailbox" src="../mail.gif" alt="Link to send me E-mail" title="Link to send me E-mail"><br>E-mail</a>
</td>
</tr></tbody></table>

<p>
<a class="image" href="http://validator.w3.org/check?uri=http://www.rossde.com/internet/ASCII_mail.html">
<img class="valid" src="../valid-html401.gif" alt="Valid HTML 4.01" title="Select this icon to revalidate this page"></a>



</p></body></html>
Comment on attachment 711060 [details]
[View > Page Source] on menu bar

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML>

<HEAD>
<TITLE>Please:  ASCII-Formatted E-Mail Only</TITLE>

<META name="Author" content="David Ross">
<META HTTP-EQUIV="Content-Type" 
	content="text/html; charset=ISO-8859-1">

<link rel="alternate" type="application/rss+xml"
  href="http://www.rossde.com/feed.xml" title="David's Web site has been  updated.">

<link rel="shortcut icon" href="../DR.ICO" type="image/x-icon">   
<link rel="icon" href="../DR.ICO" type="image/x-icon">

<meta name="description"
content="Please do not send me E-mail messages that are HTML-formatted."> 

<LINK REL="STYLESHEET" TYPE="text/css" HREF="../genl_style.css" >
<LINK REL="STYLESHEET" TYPE="text/css" HREF="internet.css" >
</HEAD>

<BODY>

<table width="100%"><tr valign="middle">
<td width="50%"><a class=image href="../viewing_site.html"><img class=browser src="../anybrowser.gif" alt="Viewable With ANY Browser" title="link to 'Viewing My Web Pages'"></a>
<p class=nostyle><b>Note:</b> My Web pages are best viewed with style sheets enabled.  
</td>
<td style="text-align: right; width: 50%"><a href="../unrated.html">Unrated</a></td>
</tr></table>


<h1>ASCII E-Mail Only</h1>
<h3 class=cphd>Copyright <a href="../copyright.html">&copy;</a> 2008-2012 by David E. Ross</h3>

<p class=lead>Please do not send me E-mail messages that are HTML-formatted.  Think!  The information you wish to convey should be expressed in well-written sentences with correct grammar, spelling, punctuation, and syntax.  You do not really need colored, strange fonts.  You do not need bold and Italics.  Does the graphic you wish to embed really provide information?  Or is it merely decoration?  

<div class=box>
<h3 class=cphd>Why HTML formatted e-mail is best avoided</h3>
<p>In general, HTML formatted e-mail is a nuisance. Normally, the effect of using HTML is that your message may appear strange or hardly legible at the recipients screen, because different e-mail clients handle HTML differently (and everybody doesn't use Micro$ofts e-mail software). One of the most annoying aspects of HTML messages is that they sometimes include graphics or sounds linked from the web, causing your dial-up networking connection to be activated and your modem to start dialing. There are other ways of irritating the receivers of your e-mail than sending it HTML coded, but few are more efficient.

<p>Parting with some of the capabilities of HTML, like the ability to insert animated graphics of smiling faces, might actually be quite beneficial for some. Without them, they may just have to rediscover the art of writing in order to convey their thoughts.

<p class=qtsrc>by J&ouml;rn R&ouml;nnow (used with permission)
</div>

<p>There are some very good reasons to avoid HTML-formatted messages:  

<ul>
<li>An HTML message is actually about 3-5 times larger than an ASCII message with the same amount of text.  
<ul>
<li>An HTML message takes 3-5 times longer to download than the same information in an ASCII message.   
<li>An HTML message takes 3-5 times longer to pass through my anti-virus scanner, even with a broadband connection.  
<li>If I keep your HTML message, it occupies 3-5 times as much disc space as the same content in an ASCII message.  
<li>Many U.S. corporations must now archive all their E-mail &mdash; internal, incoming, and outgoing &mdash; because of federal laws enacted as a result of the major corporate frauds that occurred in the beginning of the 21st century.  They want ASCII-formatted messages in order to limit their investment in archiving media.  
<div class=sideright style="width: 35%">
<p class=nostyle>*** Begin Right Sidebar ***</p>
I researched both "bloat" and HTML errors in HTML-formatted messages.  My results are presented in my <a href="ASCIIvsHTML.html">ASCII vs HTML E-Mail: Sizes and Errors</a>.
<p class=nostyle>*** End Right Sidebar ***</p>
</div>
<li>Some E-mail services limit the size of a user's inbox.  When that limit is reached, either further incoming messages are blocked or else the user must pay for additional inbox space.  Because of <a href="ASCIIvsHTML.html">bloat</a>, HTML-formatted messages will more quickly fill an inbox than will ASCII-formatted messages.  
<p>As reported by <a href="http://www.pcpro.co.uk/news/377695/ee-4g-data-caps-that-are-broken-in-5-mins">PC Pro</a>, a British 4G network is now placing a cap of 500&nbsp;MB (Mega bytes) per month for &pound;36 (US$57 at the time this was written).  In my study of "bloat" cited in the box to the right-above, I collected data from only 20 HTML-formatted E-mail messages, which totalled more than 325&nbsp;MB.  That means it would take only 31 such HTML-formatted messages to exceed a month's allowed downloading.  The same content in ASCII-formatted messages required only 96&nbsp;MB, which would then take 105 messages to exceed that limit.  
<li>Some <a href="intr_gloss.html#ISP" target="glossary" title="term defined in separate Glossary window or tab">ISPs</a> (e.g., AT&amp;T, Comcast) now limit the total bytes a user can download, levying extra charges on bytes beyond the allowed limit or even blocking further downloads.  While bloated HTML-formatted E-mail messages are unlikely to cause a recipient to reach that limit, they will cause problems for recipients who are already near ot at that limit.  
<li>Making bloat worse is the capability of some E-mail <a href="intr_gloss.html#client" target="glossary" title="term defined in separate Glossary window or tab">clients</a> that send a message that combines both HTML formatting and ASCII formatting, supposedly in an attempt to satisfy everyone.  Instead of 3-5 times larger, these messages are 4-6 times larger than mere ASCII-formatted messages.  
</ul>

<li>Many E-mail applications generate invalid HTML that does not comply with the <a href="http://www.w3.org/TR/REC-html40/">W3C HTML specification</a>.  I know.  I have taken HTML-formatted messages and processed them with the <a href="http://validator.w3.org/">W3C HTML validator</a>.  If your E-mail application is different from mine, mine might not be able to display your message properly.  Even if I can display your message, the result may be garbled if I try to quote your message in a reply to you or in a forwarded message to someone else.  

<p>Further, messages formatted in non-compliant HTML generally cannot be "read" by audio E-mail applications used by the blind.  It might be a violation of the Americans with Disabilities Act (ADA) for a business or government agency to send such HTML-formatted messages, resulting in a <a href="Webdevelopers.html#targetstore">costly lawsuit</a>.  

<li id="mal_images">Contrary to popular belief, much of the added content in an HTML-formatted message &mdash; especially graphics and background images &mdash; are attachments and not "inline".  Only when the Internet packets arrive at your E-mail application, are images merged back into the HTML.  To protect me from viruses, however, I have set my E-mail application to prevent it from opening or using any attachment.  (Yes, JPEG, GIF, BMP, and PNG image files have been known to contain <a href="http://search.us-cert.gov/search?utf8=%E2%9C%93&amp;input-form=advanced&amp;affiliate=us-cert&amp;query-or=JPEG+GIF+PNG+BMP&amp;per-page=10&amp;filter=off&amp;x=31&amp;y=9">serious malware</a>.)  As a result, your HTML-formatted message displays with "broken image" icons <img src="../broken-image.gif" width=14 height=16 alt="icon" title="icon for a broken image"> instead of your intended images.  

<li>Some spam filters treat HTML-formatted messages as more likely to be spam.  Of course, HTML formatting is not the only criterion; but when added to certain words in the message text &mdash; words that might be quite innocent &mdash; HTML formatting might be enough to make a filter reject your message.  Your message might not reach its intended addressee.  

<li>Some Web E-mail applications have options to render all messages in plain text, as if they were ASCII-formatted.  Many users select that option, in which case any effort to create HTML-formatted messages is wasted.  

<li>Plain ASCII text cannot contain a computer virus.  An HTML-formatted message, however, can contain scripts that either are viruses themselves or fetch viruses from the Internet.  

<li>Reading HTML-formatted E-mail can result in a <a href="http://en.wikipedia.org/wiki/Web_bug">Web bug</a> being downloaded into your computer.  
<blockquote title="quoting the introduction to the Wikipedia article on Web bugs">A web bug is an object that is embedded in a web page or e-mail and is usually invisible to the user but allows checking that a user has viewed the page or e-mail.</blockquote>
A Web bug might thus be considered similar to a computer virus.  At the least, a Web bug violates your privacy.  If the E-mail was <a href="spam.html">spam</a>, the sender will know not only that you actually opened the message but also how often, thus subjecting you to an increased volume of spam.  HTML-formatted E-mail rendered in plain text defeats most (but not necessarily all) Web bugs but &mdash; as noted above &mdash; also defeats the HTML formatting.  ASCII-formatted E-mail might contain Web bugs as attachments, but those Web bugs are not enabled unless you actually attempt to open the attachments.  

</ul>

<p>Most E-mail applications have options to use ASCII-formatting.  Some even have options to use ASCII-formatting automatically for selected addresses.  There is no good reason why you cannot comply with my request.  

<p>No, R&ouml;nnow and I are not alone in our rejection of HTML formatting for E-mail.  

<blockquote style="width: 45%; margin-top: 1em">Plain text is for email; HTML is for web pages
<p class=qtsrc>From someone else's message signature
</blockquote>

<p>See also:
<div class=cols>
<div class=col-left>
<img class=lft src="../ASCIIonly.gif" width=48 height=48 alt="ribbon logo for 'ASCII Only' campaign">
</div>
<div class=col-right>
<ul>
<li><a href="http://www.delorie.com/listserv/mime/">Why HTML Mail is Evil</a>
<li><a href="http://www.asciiribbon.org/">The ASCII Ribbon Campaign</a>
<li><a href="http://www.georgedillon.com/web/html_email_is_evil_still.shtml">HTML e-mail is STILL evil!</a>
</ul>
</div>
</div>

<p class=date style="clear:both">25 August 2008
<br>Updated 23 October 2012

<hr> 

<p>
<table  align="center" width="60%"><tr>
<td class=footer>
<a class=image href="index.html"><img class=internet src="internet.gif" alt="Link to Table of Contents for my Internet pages" title="Link to my 'Internet' Table of Contents"><br>"Internet" Table of Contents</a>
</td>

<td class=footer>
<a class=image href="../index.html"><img class=home src="../home.gif" alt="Link to David Ross's home page" title="Link to David Ross's home page"><br>David Ross home</a>
</td>

<td  class=footer>
<a class=image href="../mail_to_me.html"><img class=mailbox src="../mail.gif" alt="Link to send me E-mail" title="Link to send me E-mail"><br>E-mail</a>
</td>
</tr></table>

<p>
<a class=image href="http://validator.w3.org/check?uri=http://www.rossde.com/internet/ASCII_mail.html">
<img class=valid src="../valid-html401.gif" alt="Valid HTML 4.01" title="Select this icon to revalidate this page"></a>

</BODY>
</HTML>
Attachment #711060 - Attachment is obsolete: true
Attachment #711050 - Attachment is obsolete: true
Oops.  I submitted the wrong attachments.  I will resubmit the attachments.  

In the meantime, I dispute whether this is a duplicate of bug #164906.  That earlier bug complained that View Selected Source did not reflect the actual source HTML file.  It was stated there that recreating the actual source would be too complex and create an impact on performance.  Here, I merely want View Selection Source to reflect what is seen with [View > Page Source] from the menu bar.  Since the source HTML does seem readily available when [View > Page Source] is requested, the objections against bug #164906 should not apply here.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: View Selection Source Does Not Reflect the Actual Source → View Selection Source Does Not Reflect View Page Source
Note tag soup with </p> and </li> not in original HTML file, missing <!DOCTYPE> declaration, and tags that were on separate lines now combined onto single lines.
There are no </p> or </li> tags, <!DOCTYPE> declaration is present, and tags on separate lines in the original HTML file remain on separate lines.  Also, elements that have line-breaks and indentations in the original file have the same formatting here but not with View Selected Source.  

PLEASE IGNORE MY PRIOR COMMENTS GENERATED WHEN I TRIED TO FIX THE ATTACHMENTS.
Attached file RSS feed.xml file — 
The problem is even worse for an .xml file for RSS feed.  Download the attachment and view it as a document tree in your browser from a local file.
On the document tree display, drag the cursor from the top to the bottom of the page.  Then select View Selection Source.  The result (this attachment) is not recognizable.
What should happen if the selected text is purely generated by the script/css/whatever not in the original page source?
IIRC, at one point the menu option was actually labeled "View Selection DOM Source" (or something less cumbersome to that effect).

Changing it back wouldn't solve your use case, but at least it would be an accurate description of the feature.
Re comment #10:  

In those cases, what would happen with regard to [View > Page Source] from the menu bar?  At the least, View Selection Source should reflect [View > Page Source].  If the latter deviates from the source HTML file, so be it.  At least there would be some consistency.  

I know that the rendered page can easily differ from the source HTML file.  I make use of server-side includes (with UNIX scripts) that cause such differences, originating at the server when the HTML file is sent to the browser.  Anyone requesting [View > Page Source] on one of my pages that has a server-side include sees the result of my UNIX script as if I coded that result into the HTML file.
How the source is generated serverside doesn't matter to Firefox, and multiple bugs that aren't about the HTML "file" have already been duped to bug 164906, such as bug 454156, so there really is no difference from the browser's perspective. Unless you actually want this bug duped to a *duplicate* please don't reopen this bug.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: