57737 - Attached HTML file ran through ScanHTML

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect, P3)

Description

[Ben Bucksch (:BenB)]

The msg source of <news://news.mozilla.org/39F49207.3040304%40netscape.com>
contains

This is a multi-part message in MIME format.
--------------000102080007040709090506
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
-------------000102080007040709090506
Content-Type: text/html; charset=us-ascii;
 name="status.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="status.html"
[...]
  <meta name="GENERATOR" content="Mozilla/4.74 [en] (WinNT; U) [Netscape]">
  <title>Necko and Imagelib Status</title>
[...]
<li>Got CVS access <img src="chrome://messenger/skin/smile.gif" alt=":-)"
class="moz-txt-smily" height="17" width="17" align="Center"></li>

The author wrote an HTML file in 4.x, attached it in Mozilla Mailnews to a msg
and sent the "body" as (flowed) plaintext. Note that Mozilla converted :-) to a
chrome URl and sent this. This is very wrong, because other readers don't know
chrome: URLs. -> dataloss.

I wonder why Mozilla does this, because it doesn't do it for HTML "bodies".

Comment 1

[Ben Bucksch (:BenB)]

I cannot reproduce the bug via mail, and I have no access to news in Mozilla.

Comment 2

[Daniel Bratell]

Ouch. This is a bad one if it's reproducible.

Comment 3

[Ben Bucksch (:BenB)]

Can anybody post to news and try to reproduce this, please?

Comment 4

[Daniel Bratell]

Neither "Forward as attachment" nor "attach html file"  did display the bug in a 
trunk build with a random html file. Maybe you need some special html file. 

Build from CVS around 2000-10-23 on Windows 2000. The tests I did can be seen in 
netscape.test with subject "Bug 57737".

Comment 5

[selmer (gone)]

While I agree this is disappointing, I don't agree it's dataloss.  Without a
reproducible testcase there's nowhere to go with this.  Please renominate if
this can be reproduced AND there is a significant impact such as "most users
would have this problem every day."

rtm-.

Comment 6

[Ben Bucksch (:BenB)]

> I don't agree it's dataloss

The recipient doesn't see the smily ata ll, neither as ASCII nor as graphic.
Smilies sometimes change the meaning of an expression heavily.

Comment 7

[(not reading, please use [e-mail] instead)]

adding myself to the cc list.

Comment 8

[Simon Fraser [no longer active]]

This also means that forwarded messages get mangled by emoticon replacement.
Forwarded message should *always* be preserved.

Comment 9

[Jean-Francois Ducarroz]

reassign to rhp

Comment 10

[scottputterman]

reassigning to ducarroz

Comment 11

[Jean-Francois Ducarroz]

accepting and putting it back on nsbeta1 radar

Comment 12

[scottputterman]

marking nsbeta1-

Comment 13

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 14

[Ben Bucksch (:BenB)]

No mass changes, please. Thanks.

Comment 15

[Thomas D. (:thomas8)]

This bug isn't actionable.

Ben (reporter), could you please add the following (as far as possible, even partial information will help):

STR
Actual Result
Expected Result
Testcase referenced in URL (pls add as an attachment to this bug to make it accessible for analysis)

Bugs that don't follow that prescribed structure usually don't see any action for years (as is the case here) because nobody can understand them when the historical application context is gone, and important detail is missing.

Comment 16

[Thomas D. (:thomas8)]

^^

Comment 17

[Ben Bucksch (:BenB)]

> The author wrote an HTML file in 4.x

This bug was in the HTML Editor, which no longer exists.
WORKSFORME

Comment 18

[Thomas D. (:thomas8)]

(In reply to Ben Bucksch (:BenB) from comment #17)
> > The author wrote an HTML file in 4.x
> 
> This bug was in the HTML Editor, which no longer exists.
> WORKSFORME

Actually, sorry, I don't believe that, but I don't have time right now to prove otherwise.

Why did you yourself (as recently as 2010) still bother to repeatedly play down severity of this bug to "normal" against the judgement of 3 different people of QA who all marked this "critical" per http://bugzilla.mozilla.org/bug_status.html#severity because it involves dataloss?

So in 2010 you are still seeing the bug, but in 2013 it only takes you 5 minutes to arrive at "worksforme"? Certainly Editor did not disappear in or after 2010, so why didn't you close this bug on those grounds before? Worksforme usually involves testing of STR which are not even present in comment 0. If a component no longer exists, it would be "invalid".

HTML Editor or variant thereof is still used in TB's composition's editor, and I don't like to just assume that if there was a bug there, it has been fixed.

What I see is that we still have ScanHTML function in our code, so we should try to reproduce the original scenario and see if it still fails:

http://mxr.mozilla.org/comm-central/search?string=scanhtml

Ben could certainly be helpful with that, because he authored some of the respective code in the area of mozTXTToHTMLConv. Certainly he wouldn't be deliberately unhelpful or closing down bugs without further examination just because his own code could come under scrutiny...

Comment 19

[Ben Bucksch (:BenB)]

Thomas,
you said yourself "This bug isn't actionable."
*You* asked me for steps to reproduce, and I don't have any. If you have steps, then add them, and do not ask me. If you don't have steps, this bug is WORKSFORME, because this hasn't been observed in 13 years. So, until you do that, it's WORKSFORME.

If you revert my changes to a bug one more time, in any bug, you may have your edit rights revoked. You have been warned, many many many times.

Comment 20

[Thomas D. (:thomas8)]

(In reply to Ben Bucksch (:BenB) from comment #19)
> Thomas,
> you said yourself "This bug isn't actionable."
> *You* asked me for steps to reproduce, and I don't have any. If you have
> steps, then add them, and do not ask me.

Why the hostility? Since you are the reporter of this bug, I asked you very friendly in my comment 15 to restructure your comment 0 so that it conforms with the prescribed structure of any bug, in an effort to make it more understandable/reproducible. I even added that "even partial information will help", knowing that you might not be able to provide full steps. So what's unusual or offensive about asking the reporter of a bug to clarify things when they are not clear?

> If you don't have steps, this bug
> is WORKSFORME, because this hasn't been observed in 13 years. So, until you
> do that, it's WORKSFORME.

I can't follow that logic. I suppose you filed this bug for a reason, because it was actually there at the time. We all know that bugs can have a very long lifetime in TB, especially involving the internals and edge cases in question here. So no, the fact thas this hasn't been duplicated in 13 years doesn't automatically make this worksforme, which again is in deviation from the agreed definitions:

https://bugzilla.mozilla.org/page.cgi?id=fields.html

> WORKSFORME
> All attempts at reproducing this bug were futile, and reading the code produces no clues as to why
> the described behavior would occur. If more information appears later, the bug can be reopened.

- did you try to reproduce the bug before closing it? (5 minutes between my request and your response are hardly enough for that)
- did you try to read the respective code to look for clues? (again 5 minutes are hardly enough for that, and the fact that you might have written some of the code doesn't exempt you from those proceedings, on the contrary, it would make a lot of sense for you to check your own code on this).
(FTR, I'm not usually so nitpicking if not forced to in defense)

Moreover, it would be very hard to dupe against this bug given the current obscure and incomplete summary of this bug, which really can't be understood by anybody who is not privy to all the internals (again, it's very unfortunate that you are fighting so vehemently against commonly understandable and searchable summaries which comprise popular search words).

If STR are missing and cannot be found by experiment, the correct resolution is INCOMPLETE:

> INCOMPLETE
>    The problem is vaguely described with no steps to reproduce

(In reply to Ben Bucksch (:BenB) from comment #19)
> If you revert my changes to a bug one more time, in any bug, you may have
> your edit rights revoked. You have been warned, many many many times.

Ben, pls stop campaigning against me and deliberately spreading falsehoods and misrepresentations of the truth. It doesn't count as a warning when you ignore everybody's opinion and questions on bugs concerning your code and then feel insulted when I or others insist on answers. Except some very few misunderstandings, I don't usually have any problems of that sort worth mentioning with anybody else (while I certainly do make mistakes along my massive work volume, and I have no problem to admit them and apologize where appropriate).

To accuse ME of reverting YOUR changes is kind of amazing (to say the least) given that YOU yourself, (not only) on this very bug, have reverted the changes of as many as 3 recognized QA people, in deviation from accepted definitions and without giving any reason:

Comment 13 provided solid reasons for setting the severity of this bug to "critical", in accordance with the severity definitions found in the guidelines, http://bugzilla.mozilla.org/bug_status.html#severity.
In comment 14, in violation of those rules, you reverted severity from "critical" to "normal" without specifying reasons why (the fact that you dislike mass-changes doesn't justify the change). In subsequent comments, Aureliano Buendía and Wayne Mery, both respected members of TB QA team, went along their routinely QA work and changed severity back to "critical" in accordance with the guidelines (no need to spell out reasons because the guidelines were already referenced in comment 13). Again, you just silently reverted THEIR resonable changes to the bug, without giving reason. Given your non-standard estimation of severity, it was clearly YOU who was supposed to give reasons for deviating, if only for the sake of cooperation and avoiding to appear rude. It's that way of just ignoring what others say without giving sufficient answers or reasons which disturbs me most.

Per my current role, rights, duration, quantity and quality of contributions (as seen on my activity log), I'm at least as entitled to changing the resolution of a bug according to procedure as you are, and you are not the owner of any bug in Mozilla. I have reopened this bug because I have doubts that it has gone away, and I spelled out my reasons for that (even though I might have spelled them out a bit too personal).

To threaten me with revoking of my BMO canEdit rights about the first and explained change of a single, simple resolution of an ancient bug is certainly entirely disproportionate, especially given my track record of recognition in TB project (that saw my name listed in short list of TB3 credits, invitations to several Mozilla summits, "Friend of the tree 2012" award etc.). Again, given my current role, rights, duration (more than 6 years), quantity and quality of contributions (as seen from my activity log and public recognition), I'm not quite sure how one could arrive at such radical threats, which would deal a major blow (not only) to TB QA and UX, given that I'm currently terminating bugs at a speed of around 1-2 bugs almost every day, which amounts to 300-600 bugs per year, plus all those which I've pushed back into motion and which have been fixed by others after my intervention.

For anecdotal evidence, compare reactions to my everyday QA work from Ben vs. others:

- Bug 31052, comment 41: me expanding bug summary for more precision and improved retrievability; I explain shortly why that's needed for QA workflow and bug management, in spite of longer and less "aesthetic" summary
- As a result of more comprehensive summary, I subsequently find and resolve 6 duplicates of the bug, total duplicates now 19. Note that users are much more likely to file distracting duplicates when they can't find the original using popular search terms.
- After my comments and changes, discussion on resolving the bug increases
- Bug 31052, comment 48:
> If Thomas' work signifies that this bug is finally taken seriously, that would be very welcome news.
=> No problem at all, everybody happy.

Exactly the same situation, but very different reaction in one of "Ben's" bugs:

- Bug 106028, comment 32 (assigned to Ben at the time): me expanding bug summary for more precision and improved retrievability; I explain in no uncertain terms why that's needed for QA workflow and bug management, in spite of longer and less "aesthetic" summary
- I find and resolve 4 duplicates of the bug (after having found it just accidentally referenced somewhere else, would never have found the bug with previous "short" summary, nor have others: Wayne started to duplicate around one of the later duplicates, and discussion took off there).
- Shortly after my comment and changes (and pushing invitations...), Simon writes up a patch for the two bugs which were completely inactive for many years - reason to be happy, one would think
- Bug 106028, comment 38: inspite of my explicit and well-reasoned plea to keep longer summary to avoid further duplicates (currently 17), BEN REVERTS MY CHANGE of summary without any comment or explanation whatsoever (even to say "I hate long summaries" would have been more polite than just saying nothing, and in view of my comment to keep the summary, just undoing that change is really rude.)
- Bug 106028, comment 39: As Ben did not give any reasons for reverting summary against my explanation why it's needed, I revert it back, even offering Ben to keep his face by saying that maybe he reverted by accident, while leaving no doubt that I'm not happy about reverting my considerate work without reasons (because I'll be on of those few QA folks who will search the needle in the haystack thereafter to get rid of needless duplicates).
- Mike blames me for my "self-important pronouncements" - yeah, it might look that way when I'm in defense mode but it's entirely missing the point as well as history between Ben and me; surprising as even Mike himself once told Ben in bug 230423, comment 19:
> "Bucksch, don't you ever presume to close one of my bugs again."
- Bug 106028, comment 43: David tries to put out the flames, and is happy about progress in the bug (triggered by my intervention):
> @Thomas @Mike By the way, there are users facing this bug everyday... Time for change? :-)
> Thanks in advance to you guys for your precious help!
- Bug 106028, before comment 46: Ben REVERTS MY SUMMARY AGAIN, without any comment whatsoever why. That's more than rude, that's deliberate provocation, in view of my previous comments on the bug re summary.
=> Flame war, continued here.

Ben, I think we have come to a point where the personal disagreement between us is starting to be disturbing and hindering professional work, so I propose that we (Ben and me) try to talk it out personally on Skype or teamviewer asap. Contrary to Ben's perception, I have no interest in personal flame wars at all, and I've made that clear before, but I do take offence when certain standards of mutual respect and professional behaviour are not met, and when in spite of all the painstaking work that I do for the Mozilla Thunderbird project, in return I get such baseless threats in public, trying to portray me as the bad guy while I'm just doing my work as ever.

And to those of you who might think "wow, what's all this fuss about a few words in the summary" - hell no, think again, about the significance of good summaries for bug management with 10,000+ bugs (and counting) in TB/mailnews, given very slow pace of fixing, and around 5 regular/long-standing volunteers on TB QA, of which I am one.

Comment 21

[:aceman]

Thomas, thanks for all your contributions. You are right on most of the fronts you describe in your comment.

However in the case of this bug, BenB is the single reporter of this bug and nobody else stepped in as seeing the bug too. All changes by others here were just automatic or policy based ones without any specific involvement into the issue in this bug. So I think that subjectively BenB is in the right to close the bug if he does no longer see any value in developers looking after it and can't see/reproduce it anymore. But then, if he can't reproduce the steps in today program versions (maybe he does not want to install NN4 for this), then the right resolution is probably INCOMPLETE. It does not "WORKSFORME" if nobody tried to check.

Objectively, I would also like to see more explanation on why BenB thinks this bug is irrelevant today. Is the "HTML editor" (comment 17) mean to be the HTML page composer from old Netscape/Mozilla, that is now BlueGriffon and no longer used in TB?
But I think the backend of HTML editor is still used in HTML message composer. BenB are you sure this specific codepath is never hit in the composer? Also, from the original report it is not sure why you think the HTML editor caused the wrong URL. The report says the file was created in "HTML editor", but then attached to a msg and only after that converted to the wrong URL. So isn't some mime/attachment handling code of TB involved/broken here that still may exist?

Comment 22

[Thomas D. (:thomas8)]

(In reply to :aceman from comment #21)
> Objectively, I would also like to see more explanation on why BenB thinks
> this bug is irrelevant today. ...
> But I think the backend of HTML editor is still used in HTML message
> composer. BenB are you sure this specific codepath is never hit in the
> composer? Also, from the original report it is not sure why you think the
> HTML editor caused the wrong URL. The report says the file was created in
> "HTML editor", but then attached to a msg and only after that converted to
> the wrong URL. So isn't some mime/attachment handling code of TB
> involved/broken here that still may exist?

In support of that plausible hypothesis, compare the following bug which also involves  [mozTXTToHTMLConv] ScanHTML function:

Bug 234210 - [mozTXTToHTMLConv] ScanHTML runs over <head> -> "recognizes" links in <style>

Also an interesting read in terms of social interactions and systematic strategies of (not) addressing bugs in mozTXTToHTMLConv and similar code, regardless of what users and other developers are saying.

Comment 23

[Thomas D. (:thomas8)]

Given the common denominator of involving ScanHTML function, linking bugs for ease of reference.

Comment 24

[Ben Bucksch (:BenB)]

aceman, if you want to investigate this bug, whether it still exists, be my guest. If you find something seriously wrong and reproducible, by all means reopen. Me, I have never seen this bug happening on my machine, nor ever noticed a message like that again, and this consider it inconsequential or a one-off. As reporter of the bug and owner of the code, I made the call.

Comment 25

[Ben Bucksch (:BenB)]

> Why the hostility?

Because you keep messing up my bugs and bugs around code that I wrote. Not just this one, but many. And when I try to rectify it again, you insist and pick up a public fight. No thing is small enough for you to make page-long rants. You oppose me wherever you can. It seems like a hobby of yours to make my day miserable. This bug being a good example: First you question the existence of the bug and ask me to do work to prove it exists, then when I agree that it doesn't exist, you take the opposite stance and revert my closure. Reverting a developers edits *alone* is grounds for revoking edit rights, and you've done that not only once, but many many many times, and I've warned you many many many times that I will not tolerate that.

FWIW, Thomas, if you were a QA guy, you would try to reproduce this bug. That's what QA does. "QA work" doesn't mean asking other people to do work, nor messing with bug fields, it means adding actually useful information. And being QA means being unbiased, while you are on a crusade mission.

Comment 26

[Magnus Melin [:mkmelin]]

Ben: no need to be disrespectful to Thomas, we're all working for a common goal here.