diffshare / imgs Goto Github PK

問題の詳細

単体表示時の前後画像表示操作が期待通りに動作していません。具体的には、画像表示中に「←」または「→」キーを押すことで前または次の画像を表示するはずですが、常に最初の写真が表示される問題が発生しています。

再現手順

1. 任意の画像を単体表示します。
2. 「←」または「→」キーを押します。

期待する動作

• 「←」キーを押すと、その画像の前の画像が表示されること。ただし、すでに先頭に達している場合は何も表示しないこと。
• 「→」キーを押すと、その画像の後の画像が表示されること。ただし、すでに最後に達している場合は何も表示しないこと。

実際の動作

• 「←」または「→」キーを押しても常に最初の写真が表示される。

システム情報

• ブラウザ: Google Chrome 114.0.5735.110
• OS: Windows 10

この問題に対する修正の提案や追加情報があれば、それをここに記述してください。

問題の詳細

特定のアルバムで「写真詳細」をクリックすると、アプリケーションエラーが発生し、以降操作ができなくなります。エラーメッセージは「Application error: a client-side exception has occurred (see the browser console for more information)」と表示されます。

また、dev 環境では以下のようなエラーメッセージが確認されました。
"Error: Objects are not valid as a React child (found: [object Number]). If you meant to render a collection of children, use an array instead."

これらのエラーから、imgsのコード上に問題があると考えられます。

再現手順

1. 問題が発生する特定のアルバムを開きます。
2. 写真詳細をクリックします。

期待する動作

• 写真詳細が正常に表示されること。

実際の動作

• 「写真詳細」をクリックすると、アプリケーションエラーが発生し、操作ができなくなる。

システム情報

• ブラウザ: Google Chrome 114.0.5735.110
• OS: Windows 10

この問題に対する修正の提案や追加情報があれば、それをここに記述してください。

全画面において、Google Photosなどのように上にスワイプすると詳細情報が見られる仕組みが欲しい。

どうやら #31 の実装が不完全らしく、アップロード後に即時に表示される画像に対して適用されず、間違った向きで表示されることがある。

アップロード処理そのものは正しく動作しているため、別途そのページを読み直すと正しい向きで表示される。すなわち悪影響は極めて軽微である。

問題の詳細

アルバム機能が期待通りに動作していないようです。新しいブラウジングセッション（プライベートブラウジング）を開始し、アルバムにアクセスした場合、全ての画像が表示されるべきですが、一部の画像のみが表示されるという問題が確認されました。

再現手順

1. いくつかのファイルを含むアルバムを作成する
2. ブラウザで新しいプライベートブラウジングセッションを開始します。
3. アルバム機能にアクセスします。

期待する動作

全ての画像が表示される。

実際の動作

一部の画像のみが表示される。

追加情報

この問題は画像リストの順番に依存しているように見えますが、まだ詳しく調査していません。

システム情報

• ブラウザ: Google Chrome 114.0.5735.110
• OS: Windows 10

（この問題を修正するための任意の提案や情報があれば、それをここに記述してください。）

JPEG画像以外（たとえば PNG 画像）を使った場合、正しく Firebase に暗号化アップロードされ、閲覧時にも正しく表示される。しかしながら「ダウンロード」では mimetype が image/jpeg として扱われ、ブラウザによってはファイル名のデフォルトは ◯◯.jpg となるなどの影響がある。

回避策：その場合であってもファイルの中身はオリジナルの PNG 画像のままでありファイル名を手動で書き換えることで対処は可能

原因はアップロードされる画像ファイルが jpeg ファイルしか考慮されておらず、ダウンロードリンクを生成するときの blob において image/jpeg が決め打ちとなっていること。

具体的には DecryptedImage で new Blob() するときに mime type が image/jpeg 固定となっているが、ここで dec: ArrayBuffer の先頭バイトを確認して適切な mime type にするようなコードが好ましいと思われる。

アルバムを作成する時点で名前空間の確認ができる方が親切である。

問題の詳細

画像のダウンロード機能が期待通りに動作していません。具体的には、ダウンロードされる画像のファイル名が、表示されているファイル名と一致しません。

再現手順

1. 任意の画像をダウンロードします。

期待する動作

• ダウンロードが正常に開始されること。
• ダウンロードされるファイルの名前が、画像表示中のファイル名と一致すること。

実際の動作

• ダウンロードは開始されますが、ダウンロードされるファイルの名前が画像表示中のファイル名と一致しません。
• 原因としては、ダウンロードリンクの <a> 要素に download 属性が設定されていないためと思われます。

システム情報

• ブラウザ: Google Chrome 114.0.5735.110
• OS: Windows 10

この問題に対する修正の提案や追加情報があれば、それをここに記述してください。

優先度は低い。

現時点ではアルバムの画像を同時並列に読み込みしているが、画像が多い場合、すべての画像の読み込みが遅くなる。優先度が高いのは、上位に表示される画像なので、上から順番に読み込みと表示が行われていく方が良い。

lazyloadのようなものが実装できるとより良いのだが、そこまでは考えない。

アルバムというものは画像のみならず、概要、途中の文章、仕切り棒など、さまざまな表示の仕方をする可能性が考えられる。そういったものに対応できるような形式が可能かどうかの検討を行う。

メタ情報としてアップロード情報を格納。
現時点では画像は自動ダウンロードだが、モバイル回線を用いている場合を考慮して、一定以上の容量の場合はアラートで読み込みの判断を行わせる。後で見る、が可能になるように。

現状のメタ情報（filelist）は画像のファイル名の配列のみを格納している。
#14 など、今後の発展を考えると、連想配列として新しいバージョンを作成することが考えられる。

その場合、以下の手順を踏むと良さそうだ。

1. filelist.v2やmeta.v2などのように新しいメタ情報を格納する。
2. もしアルバムにmeta.v2が存在すればそれを参照して、存在しなければ既存のfilelistを参照する。
3. 既存のfilelistを読み込んだ場合、meta.v2に変換して（閲覧であっても）自動的ににアップロードする。
4. meta.v2とfilelistの双方が存在しない場合はアルバムが存在しないものとする。

縮小画像の近くに表示されるファイル名がハイパーリンク（a:link）として実装されているにもかかわらず、CSSで color: inherit; text-decoration: none; が常に設定されており、ユーザーにとってはリンクであることが視覚的に理解しにくい状態になっています。

再現手順

1. アルバムや画像一覧画面を開きます。
2. 縮小画像の近くに表示されるファイル名を確認します。

期待する動作

• ファイル名がクリック可能なリンクであることがユーザーに理解できるような視覚的なインジケーションがあること。

実際の動作

• ファイル名はリンクであるにも関わらず、CSSの設定によりリンクであることが視覚的にわかりにくい。

この問題に対する修正の提案や追加情報があれば、それをここに記述してください。

アップロードしながら完了した画像に関しては、画面遷移することなく即時に確認できる方が良い。

写真を見る場合は、背景が黒い方が集中できる。

#13 にて閲覧者によって自由に画像の順序を変えられるようにする予定である。
しかし、投稿者には、こういう風に見てほしい、という願望がある。
そこで、デフォルトの順序の制御をメタ情報から行えるようにする。

この順序は、EXIF順序のほかに、任意の順序なども設定できると良い。

Angular版で作った日本語のアルバム名のページをNext.js版で表示しても写真が読み込まれない

また、ブラウザコンソールでは https://…/filelist の XHR で 404 Not Found の応答が得られたとのエラーメッセージが確認されました。

filelist の URL では 錬成 → %E9%8C%AC%E6%88%90 のように URI escape された文字列が含まれるべきですが、 %25E9%258C%25AC%25E6%2588%2590 のようになっていました。

再現手順

1. 問題が発生する特定のアルバムを開きます。

期待する動作

• 写真が表示されること

システム情報

• 環境A
  • ブラウザ: Firefox 116
  • OS: Linux
• 環境B
  • ブラウザ: Google Chrome 115.0.5790.110
  • OS: Windows 10
• 環境C
  • ブラウザ: Microsoft Edge 115.0.1901.185
  • OS: Windows 10

以下のうち、必要と思えるもので、クライアント側で並び替えできるように。

• ファイル名
• アップロード日時
• EXIF日時
• FileListメタによる任意の順番（並び替え機能の提供）

robotによるindex化を避けるためにmetaタグの追加を検討する。

アップロードされたファイル名をUUIDやULIDに置き換える。
FileListにてオリジナルのファイル名を保持して、Zipダウンロードのときに適用する。

EXIFに35mm換算の焦点距離が含まれない場合にEXIFの他の情報を用いて導出可能かどうかの検討

現時点のコードには以下の問題がある。

1. AlbumComponentは暗号化を前提とする表示エンジンとなっている。
2. AlbumComponentはFirebaseがバックエンドであることを前提としている。

この状況は以下の点でよろしくない。

1. 非暗号化を行いアップローダー/ビューワーとして再利用しにくい。
2. Firebase以外のバックエンド（例えばS3）に引っ越ししづらい。

このことから、AlbumComponentの関心事は「ファイル投稿の受け入れ」および「画像の表示」のみとして、「ファイルの暗号化・復号」および「ファイルの格納・取得」に関しては分離する方が設計として良い。

PC上からはキーボードショートカットで十分だが、iPadのようなタブレットから操作する場合はCarouselのようなスワイプで前後の画像を見られる機能性が必要である。

現状、よく分からないファイル群が溜まっていくという状況になっており、別途、有効なURLの集約とそれ以外の不要なファイルの削除手段が必要になると考えている。

それぞれ良い方法を検討する。

• 有効なURLの集約のための手段
• 不要なファイルを決定するプロセス

#21 によって分離する場合、テスト容易性が出てくるはずなので、それを考慮して、テストコードを書く。