はてなキーワード: アドレスバーとは
簡単に書くと、Orionというブラウザをインストールし、そこに拡張機能として「コンパクトな増田」をインストールして、NGワードを設定するだけ!
https://apps.apple.com/jp/app/orion-browser-by-kagi/id1484498200
ここからインストールできる↓。以下のURLをコピペして、Orionを起動し、Orionのアドレスバーに貼り付けてください。
Orionで「Chrome拡張機能 コンパクトな増田」と検索したらトップに出てくるので、それでもいいよ!
Orionのブラウザの右下の「…」から「拡張機能」を選び、「コンパクトな増田」をオンにする。
そしたら「…」を押すと「コンパクトな増田」という項目が出てくるので、それを押す。
時々コンパクトな増田が動かなくなることがあるので、ブラウザを再起動したり、拡張機能を一度オフ→オンにしたり、「適用」ボタンを再度押したりしてみてください!
たとえば、このスレのスクショを貼って解説を頼むと以下の回答が返ってくる
Xさん、この画像はスマートフォンの画面キャプチャっぽいね。具体的には、はてな匿名ダイアリー(anond.hatelabo.jp)のページを開いている様子が表示されている。上部には「10:12」や通信状況、電池残量(36%)が示されているバーがあって、その下にブラウザのアドレスバーが「anond.hatelabo.jp」となっている。
ページ本文部分では、はてな匿名ダイアリー上で、ある記事の投稿とその反応が表示されているっぽい。日付表示「2024-12-06」の下に記事内容があり、「o1の画像理解力すげえわ ほぼ人間」といったコメント文が確認できる。これは、何らかの画像認識技術やツール(“o1”と呼ばれているもの)が人間並みの画像理解力を持つ、と感心している書き込みらしい。
また、画面上にはYという靴ブランドの広告が表示されている。黒い革靴の写真が二足並んでいるバナー広告で、上部には「Y」というロゴと靴のイメージがあり、下部にはもう一つ、横スクロールできる形で複数種類のYの革靴が表示されている(スニーカー型やチャッカブーツ風の靴が並んでいるように見える)。
記事部分には「Permalink」や「記事への反応」というリンクがあり、これははてな匿名ダイアリーの標準的なUIで、投稿記事ごとの恒久リンクや他の匿名ユーザからの反応コメントへのリンクを示すものだ。
下の方に「具体的にどんな感じ?」というコメントがあるので、これは記事投稿者や別のコメント者に対する返答か、追加質問をしているようなやり取りになっていると思われる。
まとめると、この画像は
• スマホのブラウザではてな匿名ダイアリーの記事ページを閲覧しているスクリーンショット
• コメント欄で「具体的にどんな感じ?」という質問がついている
といった状況を映している。
設定メニューからだとアドオンストアに登録されているものしか選べない
そこでアドレスバーを開き、「今回だけ使うエンジン」に🔎+アイコンが出ていればそこから追加できる(OpenSearch対応サイト)
そうでない場合、検索ボックスを右クリックして「この検索にキーワードを設定」を押す
その際に作ったブックマークを編集して、実際の検索クエリにあわせて修正する
たとえば英辞郎 on the WEBなら、URLを「https://eow.alc.co.jp/search?q=%s」のようにする
実はモバイル版Firefoxなら最初からこの形式で追加できる
PC版Chromeの設定上の追加UIが一番スマートだとは思うが
閲覧履歴から勝手に検索エンジン追加候補を提示してくれちゃうせいでアレゲなサイトまで堂々とリストに連なっているのが心臓に悪いのでやめてほしい
あとChromeのデフォルト検索エンジンにいつの間にかしれっとcoccoc.comとかいうベトナムの検索エンジンが追加されてるのは
なんか検索エンジンいじる系のマルウェアにやられたかと一瞬思ってしまうのでやめてほしい
Cốc Cốcは同名のブラウザも出しているようでChromeベースらしい
はてなにはCốc Cốcをデフォルトブラウザに設定して利用しているような剛の者がいるのだろうか
いない方に花京院の魂を賭けよう
ファイルを上位ディレクトリに移動させたいとき、昔はエクスプローラーのアドレスバー(breadcrumb?)にドラッグできたのが今はできないのが地味にめんどくさい
タブ表示ではギリ相殺されない面倒くささ
結論:
使い方がわからない・調べない・学習できない・変化についていけていないだけのアホ。
詳しい時刻もカレンダーも出ない点。
時刻はそんなに見たけりゃ秒数までタスクバーに表示できるから、クリックの必要性すら無い。
カレンダーは展開状態にしておけばクリックで普通に表示される。
なくなってない。
コンテキストメニュー的には「その他のオプション」配下になったにせよ、そもそもアドレスバー横に配置されてるし、アクセス性はむしろ向上してる。
ああ、後述の「文字表記がない😡」のせいでアレルギー起こしてるのか。
好みは分かれるところだろうけど、1回使ったら即学習できる程度のものだろうに。
老化してくると難しいのかもしれないけど。
老眼にアイコンが厳しいならショートカットキーを…ああ、覚えられないからマウス完結したいのか。
止めて欲しいならどうでもよくないんじゃん、一行でバレる嘘つくなよ。
中央配置はMacマネというより、モニタ高解像度化にともなう変化だと思うけどね。
いずれにせよ左寄せにも変更可能だし。
Windowsに求めるのは時代時代は意識してUIを今風にしすつつも、一貫した操作性であって、目新しさや新体験ではないんだわ。
変化についていけない老人にはそうなんだろうけど、世間はWinXP以前のしみったれた操作感なんて求めてないんだわ。
身の程をわきまえて欲しい。
Chromeアプリでブラウジングするとき、ほとんどすべての広告を無効化する最強の盾 = JavaScriptブロックを使ってるんだけどさ。
新聞記事とかまとめサイトとかその他、たいていのサイトはJavaScriptブロックでもちゃんと閲覧できる。
それでも、増田とかはてぶとか、なんならGoogle検索とかも、JavaScriptをオンにしておかないと、まともに動かないのよ。
そういう、なんか入力して使う系のサイトは、例外サイトとして登録しておかないといけないんだな。
だけど、Chromeアプリ、最近の更新からかな?アドレスバーに設定アイコンみたいなのが表示されて、いっぱつで例外サイト登録できるようになった。
これは革命的だよ。
もう、Chromeアプリの設定→サイトの設定→JavaScript→例外、なんて深くまで下る必要はないんだ!
超快適にブラウジングできるよ。
はてぶの上位にちょいちょい載ってるTBS系のニュースサイト、newsdig.tbs.co.jpについて。
https://b.hatena.ne.jp/site/newsdig.tbs.co.jp/
何がヤバいかって、くっそ巨大なCookie(LocalStorageとかも含むのか知らんけど)をしこたま保存してんのよ。
気付いた時点では640MBも占有してた。別に巡回チェックしてるわけでもなく、話題に挙がってたら見てみることもある程度のアクセス頻度なのだが。
Chromeユーザーはアドレスバーに↓コピペして確認してみてくれ。
chrome://settings/content/all?searchSubpage=tbs.co.jp&search=cookie
試しにCookie消去してから、ただ開いただけでサイト上で何の遷移もしてないのに279MBも保存された。
次点ではpresident.jpが553MB消費してた。(こっちも話題に挙がってたら見てみることもある程度。)
(その次にはGoogleが数百MBオーダーで消費してたけど、これはGoogleドライブのオフラインキャッシュとか考えれば妥当。他に数百MBオーダーで消費してるサイトは無かった。)
多くのサイトは数バイト~KBオーダーなのに、こいつら何保存してんのか不気味すぎる。
(追記)
各自の環境の消費量を教えてくれた方々や有意義なコメントを下さった方々ありがとうございます。
始めにお断りしておくべきだったかもしれませんが、自分はソフトウェア系ではありますが、Webエンジニアではありません。認識が浅かったり、古かったり、そもそも間違ってる可能性もあります。
CookieじゃなくてCacheStorageやんけと突っ込みもいただいていますが、「LocalStorageとかも含むのか知らんけど」と書いておいた意図は(どのような技術要素かはどうでもよくて)ユーザー端末に保存されるデータボリュームについての話を意図しています。ChromeのCookie絡みの設定画面での表示なのでこのような書き方をしましたが、解り難かったのならごめんなさいね。冗長ながらも認識齟齬を招かないように平易な表現で書くと、「ユーザの明示的な承諾なくユーザー端末に保存されるデータがデカイんだが」って話です。
で、各自の環境で「ユーザの明示的な承諾なくユーザー端末に保存されるデータ」が数GBオーダーにも及ぶという事例が少なからず報告されて、自分の環境だけではない事象だということが判りました。
さらにtbsとpresident以外にもいくつかのサイトが同様に肥大化していることも知れました。
結果的にはid:hinaloeさんの解説が解りやすかったです。ありがとうございます。
https://blog.hinaloe.net/2023/04/27/chrome-too-large-cache-storage/
CacheStorageがChromeの表示と、実際のディスク消費量と一致していないことが原因であると理解しました。
追試してみたところ私の環境ではChromeの開発者ツールでの表示が74MBで実際のWindowsのファイルシステム上は33.9MB消費されました。
実際のストレージの消費は表示値の半分程度ということになり、id:hinaloeさんの1.4GBに対して5MBのように実際の約0.3%という結果とは大きく乖離がありますので、各環境で大きく違いそうな気がします。
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage
※配下のどのディレクトリが対象サイトのものなのか一意に特定する情報が無さそうなので、Chrome開発者ツールのApplicationタブの左上の方にあるService Workersを選択すると、右側にReceived YYYY/M/D HH:MM:SSみたいな表記が有るので当該時刻に変更されたタイムスタンプを持つディレクトリを特定するような感じになるかと思います。
ついでに開発者ツールを触っていて気付いたベースで書いておくと、
といった感じで、ユーザが見たものをキャッシュしているのではなくて、先読みしてるような挙動に思えます。
ロード時間短縮でUX改善を狙ったものかもしれませんが、個人的にはそれを1か月も保持し続けるのは過剰な感じがしますが世の中的にはどうなんでしょうね?
(追記2)
hinaloe氏の投稿で紹介されているStackOverflowの投稿やそのリンク先のChromiumのバグレポートのやり取りまで目を通してみると、特に理由の説明なく平均7MBがパディングされると書かれた投稿があります。
https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses
https://bugs.chromium.org/p/chromium/issues/detail?id=796060
該当するソースコードは↓のようです。
この中で、ComputeRandomResponsePadding()という関数を呼び出しておりその実体は↓のようです。
この関数は符号無し64bit整数の乱数(つまり、0~18446744073709551615のいずれか)を14431 * 1024 = 14777344で割った剰余(つまり、0~14777343≒約14MiB)を返却します。
これがパディング値として採用されることになりますが、乱数が正規分布している前提で、平均すると(最大値14MiBの半分で)約7MBになるよねってことだと思われます。
故にChromeの設定画面から確認できるCookie等(LocalStorageとかCacheStorageとか諸々含む)のサイズは、概算してCacheStorageに存在するファイル数×平均7MBが過大計上されていることになりそうです。
これでChromeの設定画面から確認できるサイズと、実際のファイルシステム上で消費されているサイズの違いは合理的に説明できますが、TBS等の特定のサイトだけデカくみえる理由の説明にはならないのです。
なんなんすかね?