RSSの購読が自動に消えてしまう問題

[KTBN]

今、一からフィードを登録しているのですが昼間できたことができません（汗）
フィードの購読でタイトル変えてもダメですね。
昼間、やったときはフォルダの名前も変わったのですが、今はフィードのタイトルしか変わりませんね。
いろいろいじりすぎたのかもしれません。

1.通常のフィードの登録
2.フォルダペインで該当のフィード右クリック「情報を見る」内で「名前」を変更する

の方が確実ですね。すみません。

[meeyar]

patchと回避策が出揃ったようなので、遅ればせながら。

KTBNさん、Bugzillaへの報告ありがとうございました。
あなたの報告がなければ、ここでの検討の大半はなかったと思います。
「拙い英語で」とのことですが、まず報告しないことには何も始まりません。もっと誇っていいと思います。

WADAさん、Bugzillaでの対応ありがとうございました。
検討中に当方の浅知恵で色々とミスリードしてしまった感がありますが、細かくフォローしていただき大変助かりました。

さて、回避策として挙げられている、

1.フィードの購読画面で、URL入力
2.「追加」ボタンを押下
3.タイトルを濁点、半濁点のないものに変更
4.「閉じる」ボタン押下

ですが、これは当方の環境でもうまくいきませんでした。
上記手順通りにしても、フォルダペインに表示される名前はサーバ側のタイトルで強制的に上書きされてしまうようです。

Bugzillaにあるpatchを試そうと頑張りましたが、うまくbuildできず放置状態です…

[meeyar]

ついでに。
簡単にフィードの設定を解決したいという場合は、既に挙げられている

(1) アップルのフィードを購読。
(2) 購読後にタイトルを「ABCDE」に変更 ⇒ dc:title が変るのみ。
(3) フィードのフォルダー名を「VWXYZ」にリネーム
　　⇒ ファイル名が変り、それに応じてmaibox URLが書き換えられる。

が一番お手軽かと思いますが、「どうしても今までのフィードを使いたい、新規登録ではなく更新できなくなったフィードを復活させたい」というケースの対処法を書いておきます。
上記よりもやや面倒です。

1. 復活させたいフィードについて、フォルダペインの右クリック「情報を見る」からメッセージの保管場所を見ておきます。
2. フィードの名前を変更します。
3. プロファイルフォルダを開きます。(メニューのヘルプ→トラブルシューティング情報から開くのが楽)
4. 一度Thunderbirdを終了
5. 1.で調べたFeedsのフォルダ(プロファイルフォルダ/Mail/Feeds/)を開き、その中にあるFeeds.rdfをテキストエディタで開きます。
6. 復活させたいフィードのdc:titleを探し、その下に書かれている<fz:destFolder RDF:resource="mailbox://nobody@Feeds/xxxxxxxx/">のxxxxxxxxの部分を、2.で変更したのと同じ名前に書き換えて保存します。
7. 再度Thunderbirdを起動
8. フィードのfavicon表示と更新が可能になっているのを確認

この方法の場合、変更後の名前を全角文字にしてしまうと面倒なことになる(デコード前の状態で記載する必要がある)ため、半角英数字にしておくのがお勧めです。
また、dc:titleについては特に変更をかけなくてもフィードの動作に問題は出ないようです。

[WADA]

Bugzillaにあるpatchを試そうと頑張りましたが、うまくbuildできず放置状態です…

JavaScriptコードのちょこっとした修正だから、omni.ja(or .jar)をUNZIPし、ソースをテキストエディターで直して、全部をZIPし直してomni.ja(or .jar)にリネーム、で、一応の確認はできます。
ソースをいじれるから、途中でログを書かせてデータをチェックするのも、JavaScriptコードだけだからコンパイル不要で簡単。これがJavaScriptのいいところ。

[偶然的通行人]

KTBN さん、meeyar さん、WADA さん、Bugzilla への対応や Mac での動作検証など、いろいろお疲れさまです。

Thunderbird のフィードの設定に関する操作方法について、いくつかコメントさせていただきます。
当方、いまは Windows 環境しかないので、その内容で書きますから、Mac 環境や Linux 環境では、適宜読み換えてください。

（サンプル）
Thunderbird のフィードアカウントに「スラド」のフィードが登録されているとします。
　●このトピックの過去コメントに添付されている画像を参考にしてください。

（1）
メインウィンドウのフォルダペインに表示されるフォルダ構造は次のように模式化されます。

[Feeds account]
　　├ [ごみ箱]
　　└ [スラド]　…… （X）

[スラド] フォルダ（X）を右クリックしてコンテキストメニューから [購読] を選択すると、[フィードの購読] ウィンドウが開きます。

（2）
[フィードの購読] に表示されたフィード構造は次のようになります。

[Feeds account]
　　└ [スラド]　…………… （A）＝フィードアイコン表示
　　　　　└ [スラド]　…… （B）＝サイトの Favicon 表示

（A）は、フォルダペインに表示されるフィードフォルダ（X）の表示名とその定義内容です。
[フィードの購読] ウィンドウでは、（A）フォルダの配下に読み込む新しい購読先の追加などができますが、ここの名称を変更することはできません。
（A）の名称は、（X）を右クリックしてコンテキストメニューから [名前を変更] 、または [プロパティ]（Mac では [情報を見る] ？）で変更できます。この結果は次のところに反映されます。
　・フォルダペインの当該ファイル（X）の名称
　・～ \Mail\Feeds 内にある、受信したフィードコンテンツの保存ファイル名（拡張子なし）
　・feeds.rdf の fz:destFolder RDF:resource で定義されている保存先のパス情報
変更後、[フィードの購読] の（A）を見ても、変更された内容になっているのが確認できるはずです。

（B）は、feeds.rdf に記録されている基本情報を表示するとともに、[タイトル] や [フィードの URL] などを追加・変更できます。
（B）を選択し、[タイトル] にある濁点付きの日本語文字列「スラド」を、ASCII 文字だけ（例えば「SRAD」など）に書き換えます。
空欄になってしまった [フィードの URL] には、正しい URL を入れ直します。
そのあと、最下段にある [更新] ボタンを押すことで、入力した内容が feeds.rdf に反映されるはずです。
具体的には、fz:feed RDF:about 、dc:identifier 、dc:title などが書き換えられます。

（A）（B）どちらの操作でも、feeds.rdf の内容が書き換わる点に注意してください。

現状では、composed form / decomposed form が影響する文字を使わないことを前提にすれば、上記の要領で Thunderbird の UI から feeds.rdf を書き換えることができるのではないかと思います。
（実際にトラブってしまった Mac 環境の Thunderbird で、どのような動作結果になるかは、ぼくには確かめきれませんが...。）

（補足）
エンドユーザーの視点で解釈している話に過ぎませんが、いくつか。

上記の話はややこしいと思いますが、これはフィードをメールアカウントと同様に扱えるようにするための、Thunderbird 内部の独自の仕組みだと思われます。
したがって、（A）と（B）の「違い」と「関連」を把握することが、ユーザーがフィードアカウントを上手に取り扱う上での急所になるのかな、と思います。

Thunderbird のフィードアカウントは、アカウントしての "枠組み" を定義した情報だけが prefs.js に記録されています。そして、購読するフィードの URL や保存先など実際の情報は、feeds.rdf で管理されています。
一方、メールアカウトでは、メールサーバなど送受信先の取り扱いや保存先の情報などが一括して prefs.js に記録・管理されているので、このあたりが "アカウント" として根本的に異なると感じています。（より根本的には、通信プロトコルの違いなどもあるのでしょうが...。）

その上で、アカウントとしての "枠組み" 内で通用する部分の表示や動作は共通化されていて、例えばフォルダの属性が変化すれば表示されるアイコンが変わるのも、Thunderbird 上のフォルダはコンテンツの実体を保存したファイルと同等で、フォルダペインから名称変更ができるといった仕組みでも、メールとフィードに大きな差はないといえるでしょう。
同時に、それらの追加や変更がどこに、どのように反映されるかは、フィード独自の仕様があるようです。

順調に働いてさえいれば、メールとほぼ同じような操作感で使えるのが Thunderbird のフィード機能の強みですが、トラブルが起こったとき、フィードアカウントの特殊性から問題点を探るのに一苦労する ―― というのが、今回の教訓のひとつかと思いました。

本件については、ぼくも勉強になりました。みなさん、ありがとうございます。

[KTBN]

追加の情報
もし、うっかりフィードのアイコンがプレーンフォルダになった場合（早速やりました）そのまま削除しても、購読の登録が残っていて再購読できない場合があります。
その場合プレーンフォルダになったものを完全削除する前に「aaa」などの名前に変更してから削除、ゴミ箱を空にすると登録内容が残らず、再購読できるようです。
別のフィードアカウントを作って試すという方法もありますが、今の所、回避は可能のようですのでいろいろ工夫して使いましょう。

[WADA]

追加の情報
もし、うっかりフィードのアイコンがプレーンフォルダになった場合（早速やりました）そのまま削除しても、購読の登録が残っていて再購読できない場合があります。
(略)...再購読できるようです。

なんで、meeyar さんや私が何度もfeeds.rdfの内容に言及したり実際のデータを提示しているのに、偶然的通行人さんが何度もfeeds.rdfについて説明しているのに、meeyar さんが具体的にfeeds.rdfの内容を更新して問題を解決する手順をちゃんと提示しているのに、問題を報告された方からは未だにそういった情報に対する言及は一切ないのでしょう？
このスレッドのコメント全部にちゃんと目を通していますか？
meeyar さんが提示してくれたデータのおかげで、何が起こっているかがわかった今となっては、feeds.rdfの中を見さえすれば、一目瞭然...
どうしても、フォルダーペインでも見えて目に付きやすいアイコンだけに目が行き、購読画面のURLに関しては「購読」という一手間と一つ下の階層を見るという手間がかかるから...

feeds.rdfというファイルをSimpleTextでも何でもいいからテキストエディターで開いて中を覘き、既に知っているフィードのURLの文字列や"アップル"とか"スラド"といった文字列を探すだけの話なんだが、SimpleTextとかテキストエディターとかは、Mac OS Xではもう別世界の話なんだろうなぁ...
Linuxならそれは無いし、Winではnotepad.exeと言えば九分九厘通じる...

[WADA]

現在 alta88によって提示されているパッチ：
OSの種類に関わらず、NFD(decomposed form)でfz:feedにアクセスするキー(feeds.rdfの中のmailbox URL)を書き、
フィードのフォルダーからアクセスする場合も、fz:feedにアクセスするキー(feeds.rdfの中のmailbox URL)としてNFD(decomposed form)を使う。
[訂正]
キーとして使うのは、どのOSでもNFC(composed form)でした。
これなら、Linux/Winでは変更が無いのと同じで、Mac OS Xでも、今回のバグが解決されます。
古いパッチと混同してました。
[訂正おわり]

これだと、Linux/Winで既にアップルやスラドのフィードを購読している場合には、パッチをあてると今回のバグと全く同じ現象がLinux/Winで起こるので、
購読の時に新規にフアイルを作った場合に、手動で"スラド"なり"...アップル..."というファイルを作ってから購読した時と同様に、実際のOS上のファイル名を取得して、fz:feedにアクセスするキー(feeds.rdfの中のmailbox URL)を作る方法を考慮中です。

[meeyar]

Bug 1219084で提示されているattachment 8682065を試してみましたが、改善されているように見えません・・・
何か手違いなどありますでしょうか。

以下手順

1. Thunderbirdが終了した状態で、/Applications/Thunderbird.app/Contents/Resources内のomni.jaファイルを任意の場所にコピー
2. omni.jaをomni.zipに変更し展開
3. 中に含まれるFeedUtils.jsm、feed-subscriptions.js、feed-subscriptions.xulについてpatchを適用
4. 2.で展開したファイルを再度zipに圧縮し、omni.jaに改名後、/Applications/Thunderbird.app/Contents/Resourcesへ戻す
5. Thunderbirdを起動
6. フィードの設定を行い、Thunderbirdを再起動する

でやってみたのですが、再起動後は今までと同じように更新がかからない状態になっています。
こちらのミスという気もしますが、どこが違っているのかが検討つきません。
feeds.rdfの情報は、

コード: 全て選択

<fz:feed RDF:about="http://www.apple.com/jp/main/rss/hotnews/hotnews.rss"
                   fz:quickMode="false"
                   fz:options="{"version":1,"category":{"enabled":false,"prefixEnabled":false,"prefix":""}}"
                   dc:title="アップル - ホットニュース"
                   NS1:link="http://www.apple.com/jp/hotnews/"
                   dc:lastModified="Wed, 28 Oct 2015 04:05:18 GMT"
                   dc:identifier="http://www.apple.com/jp/main/rss/hotnews/hotnews.rss">
    <fz:destFolder RDF:resource="mailbox://nobody@Feeds-9/%E3%82%A2%E3%83%83%E3%83%97%E3%83%AB%20-%20%E3%83%9B%E3%83%83%E3%83%88%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9"/>
  </fz:feed>

となっており、従来と変わらない状態に見えます。

Thunderbird.app内に含まれるFeedUtils.jsm、feed-subscriptions.js、feed-subscriptions.xulについて、それぞれpatchの内容が反映されているようには見えるのですが、feed-subscriptions.jsについては行番号が若干ずれているようで、

コード: 全て選択

   1494     let moveFeed = aMoveCopy == "move";
   1495     let currentItem = this.mView.getItemAtIndex(aOldFeedIndex);
   1496     if (!currentItem ||
   1497         this.mView.getParentIndex(aOldFeedIndex) == aNewParentIndex)
   1498       // If the new parent is the same as the current parent, then do no
   1498 thing.
   1499       return;
   1500 
   1501     let currentParentIndex = this.mView.getParentIndex(aOldFeedIndex);
   1502     let currentParentItem = this.mView.getItemAtIndex(currentParentIndex
   1502 );
   1503     let currentParentResource = FeedUtils.getNormalizedFolderURI(current   
   1503 ParentItem.url);
   1504     let currentFolder = currentParentResource.QueryInterface(Ci.nsIMsgFo   
   1504 lder);
   1505 
   1506     let newParentItem = this.mView.getItemAtIndex(aNewParentIndex);
   1507     let newParentResource = FeedUtils.getNormalizedFolderURI(newParentIt   
   1507 em.url);
   1508     let newFolder = newParentResource.QueryInterface(Ci.nsIMsgFolder);
   1509 
   1510     let ds = FeedUtils.getSubscriptionsDS(currentItem.parentFolder.serve   
   1510 r);

となっていました（patchの範囲より若干前からコピーしています）。
これが今回の不具合に関連しているかどうかはわかりません。

[WADA]

Bug 1219084で提示されているattachment 8682065を試してみましたが、改善されているように見えません・・・
何か手違いなどありますでしょうか。

手順としては、間違っていないように思えますが...

あのパッチは、フィードを新規に購読した時にTbがタイトルからフォルダーを作成した場合に、feeds.rdfの中のmailbox URIに何を書くか、それをアクセスする時に何をキーにするか、というものです。
フィードを新規に購読して確認しましたか？
どのようなテストを行って、どのような結果をもって、「改善されているように見えません」と判断なさいましたか？

[追記]
行番号の違いは、提示されているものはtrunkに対するもの、omni.jaの中のものは、Tb 38のもの、という違いによるものです。
[追記おわり]

[WADA]

Bug 1219084で提示されているattachment 8682065を試してみましたが、改善されているように見えません・・・

でやってみたのですが、再起動後は今までと同じように更新がかからない状態になっていま

feeds.rdf内のmailbox URLは、NFC(composed form)になっていると思います。
再起動後はダメ、というのは、まだファイル名(decomposed form)から直接キーを生成しているのかな？
feeds.rdf内のmailbox URLを、NFD(decomposed form)に書き換えるとどうなりますか？

[WADA]

追加の情報
(略)...再購読できる「ようです」。

meeyar さんが提示してくださった、

コード: 全て選択

どちらもフォルダペイン上は「スラド」の表記です。

の時に、
従来の方法だと、

コード: 全て選択

mailbox://nobody@Feeds/%E3%82%B9%E3%83%A9%E3%83%89

の部分を、
（２）で作成した時のmailbox URLの

コード: 全て選択

mailbox://nobody@Feeds/%E3%82%B9%E3%83%A9%E3%83%88%E3%82%99

で置き換えればおしまい、という話です。

再起動後は、「（２）で作成した時のmailbox URL」で探しているのに、
フィードのtitleからファイルを作ってfeeds.rdfに登録した時点では、「従来の方法のmailbox URL」をfeeds.rdfに書いている、という問題です。
再起動前は、普通、ファイルのクローズ・オープンが入らなくて、「従来の方法のmailbox URL」で探すので見つかる。
「（２）で作成した時のmailbox URL」が、NFD(decompsed form)、
「従来の方法のmailbox URL」が、NFC(compsed form)。

そのために、再起動が入って一旦問題が起こると、
feeds.rdfのfz:feedのエントリーを見つけられないんだから、フィードを削除しても綺麗に消してくれるはずもなく、
再度購読しようにも、feeds.rdfのfz:feedのエントリーが残っているから、既にある、と拒否されて、
綺麗に消すのに思いっきり苦労させられる、と。

で、このNFD(decompsed form)と、そのutf-8形式と、それをfeeds.rdfで使っているエスケープ方式でエスケープした文字列を見つけるのに手間がかかるから、
先にフォルダー名を「SlashDot」に変えてしまえば、「mailbox://nobody@Feeds/SlashDot」に書き換えるだけで済んで楽、
というのが、meeyar さんが提示してくださった回復手順。
半角英数ならば、NFD(decompsed form)===NFC(compsed form)で、エスケープ不要。

そして、濁点・半濁点があると起こるようです、ではなくて、Unicodeにおいて、日本語の濁点・半濁点がある文字は、NFD(decompsed form) != NFC(compsed form)　で定義されているから、起こって当然、ということになります。

KTBNさんがバグを開いてくれたおかげで alta88 がすぐに来てくれて、meeyar さんが的確なデータを直ぐに提示してくださったおかげで、想定外に早く現象の解析が出来て原因がわかって、alta88 がパッチを提示してくれました。
Linux/Winで再現しないからINCOMPLETEかINVALIDかWONTFIX、好きなようにしろ、と言われて、こっちも、意地でも証拠を叩きつけてやる、とムキになったけど(^^)

既に問題が明確になっているにも関わらず、feeds.rdfの中身を一切見ようともせずに、あぁでもない、こうでもない、～のようです、などと言うのは、もう止めにしませんか。

[KTBN]

いろいろ失礼いたしました。
見てないわけではないのですが、じっくり読まないと理解しづらいものがあるので、時間的に斜め読みしています。すいません。
それと、ライブラリの中のファイルまで見たり、その他あれこれ操作するのは通常のユーザーには受け入れ自体が難しい操作なんですよ。
なので、もしそのような人の為に自分の経験から少し簡単に書いておこうと思ったまでです。

みなさまいろいろありがとうございます。感謝しています。
ただ一つ、ここにいる人はいろいろな立場があり、スキルのレベルもさまざまです。
理解はしているのですが、ここでフォローしていただける人は困っている一般ユーザに少し厳しいところがあります。
ほとんどの一般ユーザーは、自分が本当に必要な欲しい技術的な情報を検索して、ヒットさせることはかなりハードルが高いのです。
このスレ主さんもおそらく初めのほうのレスで一歩退いてしまったのだと思いますよ。
困って書き込んだ人の多くは技術的な話にはついていけません。それでも精一杯表現して助けが欲しくて書き込んでいるのだと思います。
どうかもう少し、いろいろな人に歩み寄っていただけるとより建設的なものになると思います。
タイトルとは関係なく無作法を重ねてしまいますが、ご容赦下さい。

[WADA]

(オフトピック)

理解はしているのですが、ここでフォローしていただける人は困っている一般ユーザに少し厳しいところがあります。
ほとんどの一般ユーザーは、自分が本当に必要な欲しい技術的な情報を検索して、ヒットさせることはかなりハードルが高いのです。

そうはいっても、このトピックの場合、最初は訳がわからず、今ようやく、バグを開いて問題の解析が済んで、デベロッパーによるパッチが提供された、という段階ですよね。
それで、一ボランティアであってユーザーでもあるmeeyar さんは、パッチのテストをしようとなさってくれていて、
一ボランティアであってもMac ユーザーではない私も、乗りかかかった船だから、バグのフォローをしているし、バグは英語でわかりづらいだろうからと、わかったことをこのトピックのコメントとして書いている。

にもかかわらず、「一般ユーザー」を盾にして、そういったことから得られた、たとえばfeeds.rdfについて、確認もしようとせずに、「～のようだ」ということばかり書いてくる。
今後この問題に遭遇してしまった「一般ユーザー」に対するガイドをしようとしているのならば、「～のようだ」をベースにした説明なんて、弊害こそあれ、的確なガイドとは言えないんじゃないですか？
あるいは、そういったものまで全て、「一般ユーザー」を盾にして、一ボランティアであってユーザーでもある、このフォーラムでこたえてあげようとしている人たちに、要求なさるのですか？

[WADA]

もう一点。

見てないわけではないのですが、じっくり読まないと理解しづらいものがあるので、時間的に斜め読みしています。

これって、あまりにも、このフォーラム・このトピックでフォローなさっている方々に、失礼ではないですか？
ボランティアでフォローなさっている方々が、貴重な時間を割いて調べたり確認なさって、その上で書いているコメントであって、適当な思い付きを書き連ねているわけではありません。
それを禄に読まないで、自分が思ったことだけを書き連ねる、というのは、たとえ「一般ユーザー」を盾にしたとしても、良いことだとは言えません。