Open Bug 724658 Opened 12 years ago Updated 2 years ago

View Source All Indented due to Lack of Line Numbers

Categories

(Thunderbird :: General, defect)

12 Branch
defect

Tracking

(Not tracked)

People

(Reporter: wvsrk1lx, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [workaround: comment #7])

Attachments

(4 files)

Attached image Windows Demonstration
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7

Steps to reproduce:

Within an email, go to View -> Message Source. This started happening since the 2012-02-05 thunderbird 12.0a2 update. It was not happening previously in the 2012-02-03 thunderbird 12.02. Happening for me on both Mac and Windows.


Actual results:

Every single line of HTML headers is indented.


Expected results:

Each line should not have been automatically indented.
Attached image Mac Demonstration
View message source should return the exact source of the RFC 822 message envelope. In the exact source, they are most likely indented (viewing the email Bugzilla sent me confirms that they are indeed indented, and I've read enough messages in text editors to know that this is often the course), so this is not a bug as much as it may be an unregression of a previous regression.

So unless there's a compelling reason this shouldn't be the case, this is INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
They aren't really indented. Looking at the same source in Mac mail does not reproduce the issue. The same mail viewed in Thunderbird 10 does not trigger the issue.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
This is fallout from Firefox getting line numbers in its View Source window. We just barf the entire message into the window instead of going line-by-line, so we don't get the line numbers.
The following userContent.css override removes the indentation for me:

#viewsource > pre {
  margin: 0 !important;
}

That's reversing the change to viewsource.css made by bug 246620 which set it to "margin: 0 0 0 5ch;" for accommodating the line number.

Copy-pasting from the View > Source window works fine even with the indentation (thus, no indentation in pasted content with or without the CSS override).
Phenomenon was observed. Confirming.

(In reply to rsx11m from comment #7)
> That's reversing the change to viewsource.css made by bug 246620 which set
> it to "margin: 0 0 0 5ch;" for accommodating the line number.

Does it mean that there is no plan to import "line number of View/Source" to Tb?
Note:
  Bug 246620 : Add line numbers to View Source (FIXED on 2011-12-27)
  Bugs put in "Depends on:" of bug 246620.
    Still open    : bug 469762, bug 706394, bug 713479
    Already FIXED : bug 166235, bug 482921
Status: UNCONFIRMED → NEW
Ever confirmed: true
Eh, sorry. I wanted to provide a workaround for those being bothered by the additional space to the left, I didn't mean to imply anything with respect to adding line numbering for Thunderbird or not (and it's not my call anyway).

If I understand Jim's comment #6 correctly, this would require changing the way how the MailNews code is presenting the message source to Toolkit's source viewer so that line breaks are correctly recognized.

Also, bug 713479 may provide the necessary numbering for this case, given that message/rfc822 should qualify as "non-HTML document" and thus may be covered.
Whiteboard: [workaround: comment #7]
Yes, let's please not modify libmime on the beta tree. I shudder to think of the fallout that could cause. Waiting for bug 713479 or bug 706394 would probably help too. For 11.0, we should just fix the margins and file a followup for the future.
Version: 11 → 12
Would it work via creating a new viewsource.css with the css from comment 7 and calling that from mail/base/content/viewSourceOverlay.xul ?
(In reply to :aceman from comment #11)
> Would it work via creating a new viewsource.css with the css from comment 7
> and calling that from mail/base/content/viewSourceOverlay.xul ?

Well, from what I understand, Firefox will soon have line numbers in their View Source page. That's probably something that'll be in Thunderbird as well, so I think it's more like a question of when the line numbers will be available in TB.
That's the problem (see comment #10), it's not working yet for non-HTML content and the way how Thunderbird presents the source to that window. Thus, for the time being it should be ok to just hide the non-functional line numbers and unhide them again once that functionality is available also for the mail/news message source.

From what I can tell, the suggested approach in comment #11 would do that.
rsx11m, are you familiar with such code, are you a TB developer?
Not really, mostly a user providing support and triage and occasionally throwing in a patch or two... ;-)

Specifically, I don't know how to add a new file to the manifest, but there should be other cases where this was necessary. I'd expect a specific CSS definition to omit the margin and to hide the line-number field should override Toolkit's viewsource.css definition.
My understanding is that this is actually an issue in Firefox too, so I bet we could fix it in toolkit and make everyone happy.
What is the problem in Firefox? That it does not generate numbers when TB sends the source in the special way?
According to bug 713479, this issue also occurs in Firefox for non-HTML documents (e.g. plain text).
I'm not sure if the feature does syntax highlighting as well. I think this should be enabled for every MIME type, not just text/html (and Thunderbird view source). Can't think of many reasons not to.
(In reply to tech163 from comment #19)
> Can't think of many reasons not to.

The big one: it would almost certainly require restructuring our MIME source emitter. I don't think that should going to happen for 11.0, since that's a big change for something already in beta.
(In reply to Jim Porter (:squib) from comment #20)
> The big one: it would almost certainly require restructuring our MIME source
> emitter. I don't think that should going to happen for 11.0, since that's a
> big change for something already in beta.

In my mind, I'd do something along the lines of implementing what Firefox has for the view -> source, except without the syntax highlighting. Then again, I'm not familiar with how Thunderbird is coded, so I'm not quite sure how complicated it would be.

Another thing here is, if it would be necessary to show line numbers for email source.
Keywords: regression
OS: Mac OS X → All
Hardware: x86 → All
This affects the entire source, not only the headers.
Summary: Email Headers in View Source All Indented → View Source All Indented
Summary: View Source All Indented → View Source All Indented due to Lack of Line Numbers
Are we going to need line numbers in the Email Source, like we have for HTML?
Having line numbers would make sense, e.g., when "Wrap long lines" is used, thus to make it unambiguous where a line starts and ends.
If a discussion is warranted, I would find the addition of line numbers much more useful than the removal of the margin, as well as alternating background colors (which FF does not have either without a userContent.css or Stylish adjustment), simply because it helps to visually keep your place when moving back and forth between a source window and anything else.
I'm personally undecided on whether line numbers would be necessary. Sure it would be nice to know how many lines there are in an email, but I haven't been able to convince myself if it would or would not be useful.

Then again, may not necessarily be up to us to decide.
The line numbering should be useful for any kind of code, e.g., to track down the source of messages in the Error Console. For the source view those may be less relevant, but if any of the bugs Jim mentioned in comment #10 gets implemented on the Toolkit level those may come for free without further effort necessary on the mail/news side.
Is it possible to provide an option that would disable both indenting and line numbers?  This should be under View on the Source window's menu bar.  

Or would this require a separate RFE bug report?
A menu item was suggested in bug 246620 but apparently not implemented. This would be definitely outside the scope of this specific bug report as Toolkit would need to provide such an option in the first place.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: