From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pve-devel] [RFC PATCH widget-toolkit] utils: API2Request: defer masking after layout
Date: Mon, 18 Mar 2024 16:50:29 +0100 [thread overview]
Message-ID: <e62ffbd5-4846-4ec6-85c2-4ba63d990e0b@proxmox.com> (raw)
In-Reply-To: <20240318134454.2908174-1-d.csapak@proxmox.com>
On 18/03/2024 14:44, Dominik Csapak wrote:
> since some time (not sure when exactly), the 'load()' method of the edit
> window did not correctly mask the window anymore
>
> the reason seems to be that the API2Request tries to mask the component
> before it's rendered, and that did never work correctly judging from the
> existing comment.
>
> Instead of simply calling `setLoading`, test if the component is
> rendered, and if not, mask it after it has finished it's layout.
>
> Since we cannot guarantee that the 'afterlayout' event is triggered
> before the api call response handler, add a unique id marker to the
> waitMsgTarget that is delted when the loading is done, and only trigger
s/delted/deleted/
And why do we need setting a unique ID here and not just a flag?
Can a second load be triggered before the first one finished?
> the masking if this marker is still there. (thankfully javascript is
> single threaded so this should not end up being a data race)
Note that async could cause data races also in single-threaded
code, but as we do not use that here and no yield point exist
that doesn't matter here – just mentioning it because the statement
would suggest that one could not have code that is susceptible to
such a race at all in JavaScript, which is not true.
>
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> sending as RFC because i'm unsure if we accidentally broke the masking
> somewhere along the way. AFAICS from the current code, this never could have
> worked properly? anyway, i'll be looking into that sometimes soon, and
> this patch should be correct anyway...
it surely did sometimes in the past, maybe ExtJS 7?
next prev parent reply other threads:[~2024-03-18 15:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 13:44 Dominik Csapak
2024-03-18 15:50 ` Thomas Lamprecht [this message]
2024-03-19 7:44 ` Dominik Csapak
2024-03-19 8:09 ` Dominik Csapak
2024-03-19 8:21 ` Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e62ffbd5-4846-4ec6-85c2-4ba63d990e0b@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.