Enable summary thread/message view for offline newsgroups / JavaScript Message Representation should work for newsgroups

NEW
Unassigned

Status

10 years ago
4 years ago

People

(Reporter: asuth, Unassigned)

Tracking

(Blocks: 3 bugs)

Dependency tree / graph
Bug Flags:
wanted-thunderbird +
blocking-thunderbird3 -

Firefox Tracking Flags

(blocking-thunderbird3.1 -)

Details

(Whiteboard: [no l10n impact])

(Reporter)

Description

10 years ago
Bug 447842 introduced a mechanism to build JavaScript representations of (MIME) messages.

Attachment 333703 [details] [diff] introduced on bug 447842#c10 provides a (reviewed) patch to make it work for newsgroups.  That patch has sat there pending a unit test to verify it doesn't break anything else.  This bug is being spun off to reduce confusion; the original bug will be marked fixed.

This patch would be required if gloda were ever going to index newsgroup messages.

Updated

10 years ago
Summary: JavaScript Message Representation could work for newsgroups → JavaScript Message Representation should work for newsgroups
(Reporter)

Comment 1

9 years ago
Whoops.  This bug prevents snippets in the multi-message summaries for newsgroups.  Guess we have a real reason to drive this in now.

Maybe someone else could adopt the patch and give it the unit test it wants?
Flags: blocking-thunderbird3?
(Reporter)

Updated

9 years ago
Blocks: 454829
Without this collapsed thread summary in newsgroups is pretty useless. Initially aiming at b3 in the hopes that bienvenu or someone can pick it up. We could move out to b4, but it'd be nice to have this part working for b3 as well.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b3
Perhaps jcranmer would be interested in taking a run at this one?
(In reply to comment #3)
> Perhaps jcranmer would be interested in taking a run at this one?

I would be interested, but I have very little time with which to work on it, especially as I'm trying to focus on my other blocker with what little time I have (bug 444093).
We wouldn't hold b3 for this; but if someone wants to pick it up and make it happen in time, great.  Setting Target Milestone to b4.
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0b4
Unfortunately, Attachment 333703 [details] [diff] introduced on bug 447842#c10 does break saving of attachments in newsgroups, as bienvenu feared in bug 447842#c16.
What's the failure mode?  File is corrupt?  Incompletely saved?  Not saved at all?

Updated

9 years ago
Blocks: 508694

Updated

9 years ago
Whiteboard: [no l10n impact]
The Thunderbird drivers wish to release Thunderbird 3 as soon as possible. As a
result, we feel that this bug shouldn't stand in the way of all the other good
work getting into the hands of users sooner rather than later. Therefore we are
retargeting it for 3.1. See http://ccgi.standard8.plus.com/blog/archives/242
for more details. The 3.1 release is expected to be a quick release soon after
Thunderbird 3.
Flags: blocking-thunderbird3.1+
Flags: blocking-thunderbird3-
Flags: blocking-thunderbird3+
Target Milestone: Thunderbird 3.0b4 → ---
No longer blocks: 508694
Depends on: 508694
Due to the incomplete information of the summary view for all types of newsgroups, bug 508694 has now disabled the summary view for all newsgroups.

This bug should re-enable it for offline newsgroups when it does the required message representation.
Summary: JavaScript Message Representation should work for newsgroups → Enable summary thread/message view for offline newsgroups / JavaScript Message Representation should work for newsgroups
We'd love to get this, but we wouldn't hold 3.1 if it were the last bug standing.  blocking- and wanted+ set.
blocking-thunderbird3.1: --- → -
Flags: blocking-thunderbird3.1+ → wanted-thunderbird+

Comment 11

8 years ago
Did anyone ever figure out why attachment 333703 [details] [diff] [review] broke attachments? If someone has some ideas for how to fix this, I could look at it.
(In reply to Jim Porter (:squib) from comment #11)
> Did anyone ever figure out why attachment 333703 [details] [diff] [review] [diff] [details] [review]
> broke attachments? If someone has some ideas for how to fix this, I could
> look at it.

This has been discussed at least once on IRC in detail. To summarize the conversation, in case my IRC logs find the wrong end of a cosmic ray:

Essentially, for gloda to get what it wants, it adds on extra details to the URI. However, for various reasons, news URIs get almost instantaneously rewritten, which drops the extra details. When these URIs get rewritten, the extra data gets stuffed into the original spec.

What the patch attempted to do was to yank the data out of the original spec instead of the rewritten URI. Since news URIs are extremely fragile (I remember remarking at one point in time how the system ever worked), this naturally caused things to break, in this case attachments. Indeed, when I tried to rip out the original spec code in my URI parser rewrite, I found that the result was so horribly broken the only tenable option was to keep it going.

At a more specific level, it could be that attachments were broken because the parser figured out the wrong action for the URI; since the rewrite causes the actions to be essentially propagated without needing to reparse the URI much of the time, this could no longer be an issue. The fix I suggested was to replicate the aAdditionalHeader logic in StreamMessage to add to the new, synthesized URI. I don't know enough about the gloda architecture to know if this is sufficient, but this should allow gloda to work with no breakage in news code...
Blocks: 241197

Updated

7 years ago
Blocks: 737347

Updated

4 years ago
See Also: → bug 545365
You need to log in before you can comment on or make changes to this bug.