デスクトップ復元系+ブラウザ枠バグはどう - 秀丸エディタ関連ソフト会議室 - スレッド41816, 2025/03/23

デスクトップ復元系+ブラウザ枠バグはどう

こみやんま さん　25/03/23 11:03

この辺の修正どうしましょうか...
https://www.maruo.co.jp/hidesoft/4/x10542_.html#10542

こちらなど、いくつか報告があったため、直しかけたものを、元へと戻したのだと思
います
https://www.maruo.co.jp/hidesoft/2/x41702_.html#41702

問題は、現状のままだと、

---------------------------
// 自動起動マクロ（ファイルを開いた時）
// OnEventMacros.mac

// .htmlなら個別ブラウザ枠にも表示
if (filetype == ".html") {
showbrowserpane 1, 2;
setbrowserpaneurl filename2, 2;
}

このような簡易なものすら「実はデスクトップ復元」を使われてしまうと、正しく機
能しない、ということだと思います。
10542 の投稿時に秀丸担当さんの方で調べて認識しているハズだとは思いますが、一
応の記載

①バグ再現
a.html、b.html、c.html、d.html、e.html それぞれに「a, b, c, d, e」とだけ記述
した５つのファイルを用意

②５つのファイルを開いてデスクトップの保存

③上にある「いかにもやりそうな簡易な自動起動マクロ」を用意。

④全てファイルを閉じる

⑤デスクトップの復元

⑥バグ内容
　おそらく(５つ中）「少なくて１つ」、「多くて２つ」のファイルが正しく個別ブ
ラウザ枠で描画されない。
　（描画は真っ白[ or 真っ黒もあるのか？)

この対処のどのような方向にするか考えておく必要があるかと思います。
（これを「ん～バグったままでよし」という方向はさすがに、かなり苦しいような気
がします...）

このバグが輪をかけて苦しいところは、
```
一度こうなるご、該当の個別ブラウザ枠の描画が立ち直らない
```
ということです。
「個別ブラウザ枠」を利用する(マクロも含め)全てが機能しなくなったも同然となり
ます。

一度、個別ブラウザ枠のインスタンス自体を show:0 なりして破棄が必要であり、
現状このようなバグがあることまでもを想定してマクロを組み上げている人は居ない
とおもいまする。

RE:41816 デスクトップ復元系+ブラウザ枠

秀丸担当 さん　25/03/24 09:46

この問題は、デスクトップ復元時のマクロ実行タイミングが１つ前のものということ
に起因しています。
１つ前ではなく確実に順次実行とするのは、不可能ではないと思いますが、実際は問
題が起きてしまってデリケートな部分でした。
もし順次実行が安定して確実にできそうであればしたいです。
できたらあまりいじらず安定のままとしたいところです。

ブラウザ枠の問題はそれが影響して結果としで現れますが、本質的にはWebView2その
ものの問題のようです。デスクトップ復元でなくても、ウィンドウが非表示のときに
ブラウザ枠を出すような操作で問題になると思われます。
PreferredColorSchemeの問題もそうですが、WebView2が直接的に問題となっているこ
とはどうしようもないので、避けるほかないです。
PreferredColorSchemeは使わないようにして回避できましたが、非表示時の問題は対
策が難しく、こういった使い方は避けるようにお願いする方向にもっていくしかない
かもしれません。

RE:41817 デスクトップ復元系+ブラウザ枠

こみやんま さん　25/03/24 10:53

最も難しいのは、マクロやプログラムからはいずれも「正常に動作している」かのよ
うになる点です。

異常は、「人間の目」もしくは「デバイスコンテキストレベル」で描画を確認しない
と判断できません。
（デバイスコンテキストレベルでもちょっと自動判断は困難な気がしまます）

■ 対策について

① 描画の異常検知

WebView2描画にバグが発生した、または
描画バグが発生しそうなタイミングで、WebView2のブラウザ枠が描画されたという状
況を、そちらで把握することは可能でしょうか？

(WebView2を「呼び出した際のフロントウィンドウハンドル」と、実際に「描画され
た時のフロントウィンドウハンドル」が異なる状況の時に乱れる的なモノに近いので
はないかと推測しています。）

もし、秀丸側で「今、危ないタイミングだ」と判断できる情報があれば、マクロ側か
ら「もう一度実行すればいいか」という対応を取ることができます。

② デスクトップ復元中の検知

もし、①が、曖昧で難しいようであれば、
「デスクトップ復元によるウィンドウ展開中」という情報だけでも把握できれば、マ
クロ側で対処できるとは思います。

(非同期限定にはなってしまうけれども、
「デスクトップ復元中 & hidemaruorderが0ではない」という状況の間は、
マクロ内でbrowserpanecommadのshowの実行を遅らせることで
ほとんど潰れるのではないかとは思います。

RE:41818 デスクトップ復元系+ブラウザ枠

こみやんま さん　25/03/24 11:29

var timerHandle;

function waitForOwnerBrowserPane() {
var wait = false;
if ( hidemaru.inputStatus() & **** == 1) { // デスクトップ復元中をinputS
tatusに入れたとして...（非同期関数ならなんでもいい）) {
wait = true;
}
if ( 秀丸のウィンドウの幅 <= 0 ) {
wait = true;
}
if ( hidemaruorder(hidemaru.getCurrentWindowHandle()) > 0 ) { // hidemar
uorder は非同期化の必要あり...
wait = true;
}

if (!wait) {
browserpanecommand({
...
show: 1
});
}

hidemaru.setTimeout(waitForOwnerBrowserPane, 500);
}

みたいにできればとりあえず最低限なんとかなるんじゃないかと。

上の３つとかの条件を判定するようなものを、秀丸側から、broswerspanecommand("m
akesafe");
みたいなのが提供できればいいでしょうが、
ちゃんと動作するものという意味では困難なので、
各ユーザーに投げるしかないかなぁ...

一番は普通に正しく動作することですが、
それが困難なら、あまりに目立っててそもそも避けること自体が難しい
ところだけでも埋めるしかないかと思います。

RE:41819 デスクトップ復元系+ブラウザ枠

秀丸担当 さん　25/03/24 15:28

デスクトップ復元は、確実に順次実行ができたとしても、さらに重くなります。
そうなると、マクロ側は時間差でブラウザ枠・レンダリング枠を表示させたいという
発想になると思います。
時間差で実行させると、タブモードで裏の非表示状態にあるところで実行されること
になり、そこでまた問題が発生することになります。
デスクトップ復元自体は問題ではないのと、対策したとしても結局また問題に当たる
可能性はあるので、デスクトップ復元の対策はやめておこうと思います。

非表示状態の問題は、既知の問題としてどこかに書いておこうと思います。
気休め程度にならないかもしれませんが、ウィンドウが非表示状態かどうかを知る方
法があったらいいです。
hidemaruorderは自分自身は常に0となって判断はできませんでした。
windowstateというのがありますが、アクティブじゃないタブは判断できないので、W
indows的に本当に非表示かどうかをwindowstate2で知れたらいいです。（非同期対応
もして）

RE:41820 デスクトップ復元系+ブラウザ枠

こみやんま さん　25/03/24 16:44

>デスクトップ復元は、確実に順次実行ができたとしても、さらに重くなります。
>そうなると、マクロ側は時間差でブラウザ枠・レンダリング枠を表示させたいとい
>う発想になると思います。
>時間差で実行させると、タブモードで裏の非表示状態にあるところで実行されるこ
>とになり、そこでまた問題が発生することになります。

なので、「ユーザー自身がjavascriptでも使ってマニュアルで対策」可能な道具は提
供して欲しい、
という提案です。

・デスクトップ復元中であるという判定
　直接はデスクトップ復元のせいではないですが、
　結局現状ブラウザ枠起動にとって一番危険なタイミングなので
　(表示バグ率４割とか、ここにほとんどが集約するかと）

秀丸本体側が対策するのではなく、ユーザー自身が

function waitSafeOwnerWebView2Pane() {
var wait = false;
if ( **** ) { // デスクトップ復元中
wait = true;
}
if ( **** ) { // カレントウィンドウが、ウィンドウ幅がない(アイコニックか
非表示)
wait = true;
}
if ( **** ) { // カレントウィンドウがトップじゃない
wait = true;
}

// すべてクリアしてる時だけ表示
if (!wait) {
browserpanecommand( { show } );
}

hideamru.setTimeout(waitSafeOwnerBrowserPane, 1000);
}

// マクロがこれで終わるから「デスクトップ復元中」などであれば次へといく(アク
ティブが再び帰ってくるまでは表示されない)
hideamru.setTimeout(waitSafeOwnerBrowserPane, 0);

みたいに「ユーザー自身」がやれば、
ほとんどのケースは大丈夫になると思うのですが、
ならないですか？

デスクトップ復元中はある意味予約だけが発動する感じになり、
ユーザーがそのタブをアクティブにしたら
browserpanecommand がやっと発動する感じになるので、相当高確率で無事に表示出
来るかと思います。
(もちろん100％ではないでしょうが、今のデスクトップ復元みたく４割表示がバグる
みたいな感じではなく、他の操作と少々あわせても
常識的な操作なら遭遇確率は1％すらない、みたいにはなるかと)

しかも上の処理だと、普通にウィンドウを開いただけの時は、ほとんど遅くならない
ですし。
(30ミリ秒程度はそれまでよりは遅れるでしょうけれども)

担当さん提案の windowstate2() で
ほとんど同じような対策がとれるよ、ということであれば、
それでよいと思います。

秀丸本体で対策が無理なのであれば、割り切って
「ユーザーがここまでこうやって(jsなどで)キッチリ書けば、
　一応ほとんどのシーンで対策はとれますよ」という形でもっていくしかないかと思
います。

（あるいは C++でもC#でもJSでもなんでもいいですが、
これ書いて wait しとけば、ほとんど問題なく制御できるよ、っていうのがあれば
気付きとなります～）

RE:41821 デスクトップ復元系+ブラウザ枠

(-L-) さん　25/03/24 17:41

>（あるいは C++でもC#でもJSでもなんでもいいですが、
> これ書いて wait しとけば、ほとんど問題なく制御できるよ、っていうのがあれば
>気付きとなります～）

秀丸（＋マクロ）の世界で実現すべき内容なのかさえわからないほど話が高度すぎて
ついていけませんが、横から失礼します。
（秀丸ユーザーの一般人として影響があるシーンの具体的なイメージができませんで
した。。）

なんでもいいのであれば、秀丸の外から、対象の秀丸ウィンドウ（複数それぞれ？）
に対して、マクロを起動させるとか、ブラウザ枠を表示させるとかを操作すれば良い
のではないでしょうか。
（例えばperlの場合の、Win32::GuiTestでウィンドウを探索＆該当ウィンドウに対し
てマクロ起動したり、各種メニューの操作をする。みたいなイメージ）

RE:41822 デスクトップ復元系+ブラウザ枠

こみやんま さん　25/03/24 17:59

>（秀丸ユーザーの一般人として影響があるシーンの具体的なイメージができません
>でした。。）

普通に　「.htmlファイル」を秀丸で開いた時に、自動的に右のブラウザに表示する」、
というのが(複数ファイルだと)４割の確率でバグりますよ、ということです。

デスクトップ復元で「複数のファイルが復元」されてしまうと、非常に高確率でバグ
ります。

マークダウンも同じです。マークダウンファイルを秀丸で開いた時に
右にマークダウン結果を描画する、というのが４割もの非常に高い確率でウィンドウ
が何も表示されなくなっている、ということです。
（デスクトップ復元だと）

RE:41823 デスクトップ復元系+ブラウザ枠

(-L-) さん　25/03/24 18:15

>（デスクトップ復元だと）

ありがとうございました。イメージできました。

秀丸のデスクトップ復元を全く使わないので、個人的には影響がない話なのですね。
その立場からすると、秀丸のデスクトップ復元時は自動起動マクロは無効という仕様
で構わないのですが、世の中的にはそうではないってことなのかしら。

このデスクトップ復元機能が搭載された頃と、今とではOSを始め、周辺の（窓管理）
アプリの状況も異なっているであろうにも関わらず今でも秀丸にデスクトップ復元機
能が残っているのは、単純に過去からの名残りなのか、それとも秀丸ならではの便利
機能があるからなのかしら。

ただの名残りなら、デスクトップ保存・復元機能も廃止しちゃうことも視野に入れて
もいいような気がしてしまいます。
（この機能を使わない個人的には、秀丸のメニューがよりシンプルになって良い。）

RE:41824 デスクトップ復元系+ブラウザ枠

こみやんま さん　25/03/24 18:19

>このデスクトップ復元機能が搭載された頃と、今とではOSを始め、周辺の（窓管
>理）アプリの状況も異なっているであろうにも関わらず今でも秀

うーん、そのような機能が主目的ではなく、VSCodeなどではデフォルトで最後に開い
ていたウィンドウは全部開き直すんですが、
基本的には「最後に開いていた何個かのウィンドウ」を「全部開き直す」というのが
主目的ですかねぇ
（まぁ位置とかも復元してくれはしますが、そっちはそんなに重要ではないですｗ）

私も現役の頃は日常的に使っていたのですが、
もう仕事をしておらず（投資家になってしまったので）使ってなかったので
気づくのが遅れました。

RE:41825 デスクトップ復元系+ブラウザ枠

Fzok4234 さん　25/03/25 08:45

横から失礼いたします。Fzok4234 です。

このスレッドのやり取りを眺めていて感じたことは、現在のデスクトップ復元の機能
が、保存されていた
ウインドウ / タブに対応するファイルを「何がなんでも全部」開いて復元してしま
うことこそが、問題の
本質ではないでしょうか。

すなわち、復元された全てのウインドウ / タブにおいて
・ファイルの読み込み。
・自動起動マクロの実行。
・強調表示の適用。
・レンダリング。
といった開く処理を、ウインドウ / タブの並び順に 1 つずつ行っていくという仕様
が諸悪の根源という
ことです。

当然、自動起動マクロの実行主体が各ウインドウ / タブのプロセスに次々と移って
いくため、ブラウザー枠への
入出力が複数のプロセスから同時に行われるため動作がおかしくなります。かといっ
て 1 つのウインドウ /
タブがブラウザー枠に排他制御をかけたりしたらデッドロックの恐れもあります。

そもそも、このような一斉読み込みには「動作が重い」という根本的な問題がありま
す。例えば、復元させる
各ウインドウ / タブが
・巨大なファイル。
・ネットワークパス上のファイル。
・重い自動起動マクロ。
・重い正規表現を使った強調表示。
といった要因で開き切るのに時間が掛かる場合、数が多いと秀丸エディタが操作可能
になるまで相当待たされて
ユーザーにとってかなりのストレスとなります。しかも 60 秒以上復元に時間が掛か
るとタイムアウトで
処理が打ち切られてしまいます。

そこで、秀丸担当さんにも検討していただきたいのが、復元させたウインドウ / タ
ブの内アクティブな
最上位の 1 つだけ読み込み処理を行うという「消極的な」デスクトップ復元の実装
です。

すなわち、復元の際に各ファイルに対応するウインドウ / タブの外枠の生成だけを
行って読み込みをすぐには
行わず、まず最上位の 1 つのウインドウ / タブだけで読み込み処理を行った後は、
残りのウインドウ / タブの
読み込みは保留にして直ちにユーザーが操作可能な状態にします。

そして、残りのウインドウ / タブはそれぞれユーザーがクリックするなどしてアク
ティブになったときに
初めて読み込み処理を行うようにします。

こうすれば、デスクトップ復元コマンドを実行後に呼び出される自動起動マクロは最
上位のウインドウ / タブの
物の 1 個だけとなり、複数の自動起動マクロの同時実行による不具合は回避できま
す。何より、動作が非常に軽く
なってユーザーのストレスが大幅に軽減されます。

このような消極的なタブ復元は、Web ブラウザーの Firefox で既に実用化されてい
ます。Firefox で複数の
タブを開いたまま終了させると、次回起動させたときにタブが復元されますが、起動
直後は前回終了時に
アクティブだった 1 個のタブのみ Web ページのダウンロード / 表示が行われます。
残りのタブはユーザーが
クリックしてアクティブになったときに初めてダウンロード / 表示の処理が行われ
ます。このため、起動の
動作が軽くてメモリーの消費量が少ないという特徴があります。

反面、Chrome では復元させた全てのタブで一斉にダウンロード / 表示が行われるた
め、動作が重くて
メモリーもたくさん食います。

RE:41825 デスクトップ復元系+ブラウザ枠

秀丸担当 さん　25/03/25 09:00

>その立場からすると、秀丸のデスクトップ復元時は自動起動マクロは無効という仕
>様で構わないのですが、世の中的にはそうではないってことなのかしら。

デスクトップ復元時の自動起動マクロは、通常は動作しないようになっています。
ファイルを開いた直後の自動起動マクロを設定し、さらに[>>]ボタンからデスクトッ
プ復元時も実行するものを選んで、誤動作の可能性があることに了承したときのみ実
行できる設定です。
具体的な問題の例としてレンダリング枠・ブラウザ枠のことも書いておこうと思いま
す。

直接的な問題はデスクトップ復元ではなく、たまたまそこで起きやすいというだけで
す。
inputstatesでデスクトップ復元中であることや、windowstate2でウィンドウの非表
示状態も得られるようにしておこうと思いますが、これがあればレンダリング枠等で
対策できるわけではない、という位置づけにしておきたいです。
もしかしたらWindowsの従来アプリとしての親ウィンドウがあって、子ウィンドウが
あって、という構成とは違うやり方であればできたりするのかもしれないですが、そ
こまではやらないです。
既知の問題があるので、そういう使い方は避けるようにしてください、ということに
したいです。

RE:41826 デスクトップ復元系+ブラウザ枠

(-L-) さん　25/03/25 09:23

>このような消極的なタブ復元は、Web ブラウザーの Firefox で既に実用化されてい
>ます。Firefox で複数の

消極的なタブ復元には一票いれたいです。
（復元を使わないのは、復帰時重たいことを嫌うのも理由にあります）

ただ、個人的には、ファイルヒストリが使いやすくなる方に向かってもらえると有り
難いです。

ファイルヒストリで、たとえば、index.htmlとか、indとか、*.htmlとかでヒストリ
から検索されて、そこから選べて過去に編集したものを呼び出せるとか、メニュー選
択したときだけの動きで構わないので、すでに存在しないファイルのヒストリは履歴
から削除される機能とか、ファイルヒストリには、複数ファイルの編集(グループ)と
しても記憶できていて、グループで呼び出せは、複数ファイルを呼び出せたりとか、
そのグループの中の個別ファイルを選択して呼び出すこともできたりとか。

こっちの機能があれば、保存・復元機能は使わずに、ファイルヒストリで過去編集状
況を復活させたり、一部ファイルだけ呼び出したり、単純に過去編集したファイルを
呼び戻したりが便利なんだよなぁ。と思いながら、ファイラから秀丸にドロップして
いる毎日です。

RE:41828 デスクトップ復元系+ブラウザ枠

秀丸担当 さん　25/03/25 12:33

一応ネタとしてはあり、互換性も考えると難しいですが、ご意見参考にさせていただ
きます。

RE:41827 9.46.β2

こみやんま さん　25/03/25 21:14

例の inputstate と windowstate2 で結構うまく動いておるのでは？という気がし
ます。

自動起動マクロ自体を直す感じで以下みたいにしました。

（今まで使っていた自動起動マクロ名は「OnEventMacroMain.mac」とする)

// ---- 新自動起動マクロ OnEventMacro.mac
hidemaruversion "9.46.02";

// 自動起動マクロでファイルを開いた時は、予約形式にする
if (event == 1) {

jsmode "JScript\\" + currentmacrofilename;

js {
var currentMacroDirectory = currentmacrodirectory(); // 非同期になる
と取れないため、取得

function isSafeMakeConditionOfWebView2Pane() {

// タブモードでアクティブではない非表示
if( (windowstate2() & 0x0004) != 0 ){
return false;
}

// デスクトップ復元中
if (inputstates() & 0x00080000) {
return false;
}

return true;
}

var timerHandle; // 宣言だけ。初期化しないこと

if (typeof("timerHandle") != "undefined") {
hidemaru.clearTimeout(timerHandle);
}

// マクロ実行を予約する
function reserveExecMacroFile(macroFileFullPath) {
// ダメなタイミングなら、0.5秒後にまたチェック
if (!isSafeMakeConditionOfWebView2Pane()) {
timerHandle = hidemaru.setTimeout(reserveExecMacroFile, 500,
macroFileFullPath);
return;
}

// 大丈夫そうなので、マクロ実行を予約
hidemaru.setTimeout( function() {
var isScheduled = hidemaru.postExecMacroFile(macroFileFullPa
th, 1);
if (isScheduled) {
hidemaru.clearTimeout(timerHandle);
} else {
// マクロ予約自体が失敗しているので、0.2秒後にまたチェック
timerHandle = hidemaru.setTimeout(reserveExecMacroFile,
200, macroFileFullPath);
}
}, 0
);
}

reserveExecMacroFile(currentMacroDirectory + "\\OnEventMacrosMain.ma
c");
}

// それ以外はこれまで通り
} else {
execmacro currentmacrodirectory + "\\OnEventMacrosMain.mac";
}

// ---- 旧自動起動マクロ OnEventMacroMain.mac

先頭の部分のみ修正

if (argcount > 0) {
#eventID = val(getarg(0));
} else {
#eventID = event;
}

で、event の代わりに、#eventID を使う。これまで通り。

これで、「デスクトップ復元」の間は、自動起動マクロは「予約だけ」されて、
実際の実行は、タブを始めてアクティブにした時に実行される形となったので、
ほぼ想定していた動作となりました。

「ファイルを開いた時」に自動起動していた
個別ブラウザ枠やレンダリング枠を使うのもの、
バグなく上手くいってると思います。

RE:41831 9.46.β2

こみやんま さん　25/03/25 23:12

すみません、私、スレッドの先頭の投稿の引用を間違ってたみたいですねｗ

https://www.maruo.co.jp/hidesoft/4/x10561_.html#10561

の話でした。

(間違えてWebView2の背景の変更のを引用してました）

親の OnEventMacro.mac 投稿のですが、
あくまで(そこの担当さんのレスにあるよう) tabmode の時だけ発生するようすなので、

hidemaruversion "9.46.02";

// 自動起動マクロでファイルを開いた時は、予約形式にする
if (event == 1 && tabmode) { // tabmode 限定
jsmode "JScript\\" + currentmacrofilename;
... （親の投稿と同じ)

// それ以外はこれまで通り
} else {

execmacro currentmacrodirectory + "\\OnEventMacrosMain.mac";
}

みたいにやる必要があるみたいです。