public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Shannon Sterz" <s.sterz@proxmox.com>
To: "Fiona Ebner" <f.ebner@proxmox.com>,
	"Proxmox Backup Server development discussion"
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] ui: check that store is set before trying to select in GCJobView
Date: Thu, 28 Nov 2024 15:41:09 +0100	[thread overview]
Message-ID: <D5XW27OXAB6E.BUIKTFN37CK5@proxmox.com> (raw)
In-Reply-To: <2a4b6b22-09a3-473a-ba37-fe30ae865e8a@proxmox.com>

On Thu Nov 28, 2024 at 3:15 PM CET, Fiona Ebner wrote:
> Am 28.11.24 um 14:49 schrieb Shannon Sterz:
> > otherwise users will get a `b.store is null` error in the console and
> > a loading spinner is shown for a while.
> >
> > the issue in question seems to stem from the event handler that gets
> > attached when the "Prune & GC Jobs" tab is opened for a specific
> > datastore. however, that event handler should *not* be attached for
> > the "Datastore" -> "Prune & GC Jobs" panel. it seems that the event
> > handler does still get attached, and will fire in the "Datastore"
> > view if it hasn't fired while opened in a specific datastore
> > (it should only trigger a single time).
> >
> > that scenario seems to occur when a different tab was previously
> > selected in a specific datastore and navigation is triggered via the
> > side bar from the "Datastore" -> "Prune GC Jobs" to a specific
> > datastore. that leads to the "Prune & GC Jobs" view for that specific
> > datastore being opened very briefly in which the event handler gets
> > attached, navigation then automatically moves to the previously
> > selected tab. this will stop the store from updating ensuring that
> > the event is never triggered. when we then move to
> > the "Datastore" -> "Prune & GC Jobs" tab again the event handler will
> > be triggered but the store of the view is null leading to the error.
> >
> > Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
> > ---
> >  www/config/GCView.js | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/www/config/GCView.js b/www/config/GCView.js
> > index a6e79fb3..51ce1cb6 100644
> > --- a/www/config/GCView.js
> > +++ b/www/config/GCView.js
> > @@ -33,7 +33,11 @@ Ext.define('PBS.config.GCJobView', {
> >  		// after the store is loaded, select the row to enable the Edit,.. buttons
> >  		store.rstore.proxy.on({
> >  		    'afterload': {
> > -			fn: () => view.getSelectionModel().select(0),
> > +			fn: () => {
> > +			    if (view.store) {
> > +				view.getSelectionModel().select(0);
>

we've already talked about this off-list, but i wanted to document that
a bit better, so here goes nothing:

> In my testing, view.store is set if I was previously at a datastore's
> "Prune & GC Jobs" but not if I was on a different tab from a datastore.

yeah this is super confusing and requires setting the break points just
right to get to. datastore is set, if it was set by navigating to a
specific datastore's "Prune & GC Jobs" tab first as you pointed out and
isn't reset when you are in the top level "Datastore" panel.

in testing i tried to explicitly reset it to `undefined` in the
"Datastore" -> "Prune & GC Jobs" panel, but that would only avoid this
bug in certain situations. it was still possible to trigger it with the
navigation pattern described above.

> In both cases, the row does not seem to be selected and the "Edit" and
> "Run Now" buttons are still grayed out. So your patch is certainly an
> improvement, because there is no error and loading :) But it still
> doesn't seem to do what was intended according to the code comment.

it does select the row logically only in the specific datastore's "Prune
& GC Jobs" panel, as there should only ever be one GC job there. this
enables the "Edit" and "Run now" buttons without the user having to
select the single line in the table. (note that the highlighting is
removed, so visually nothing *looks* selected)

however, for the overview of all GC Jobs in the "Datastore" -> "Prune &
GC Jobs" panel, nothing should be auto-selected. hence, the `if
(view.datastore)` check before the event handler is attached. as
described in my commit message, it is still possible under certain
circumstance to have the event handler be attached and be triggered
here.

> > +			    }
> > +			},
> >  			single: true,
> >  		    },
> >  		});



_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel


  parent reply	other threads:[~2024-11-28 14:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-28 13:49 Shannon Sterz
2024-11-28 14:15 ` Fiona Ebner
2024-11-28 14:37   ` Fiona Ebner
2024-11-28 14:41   ` Shannon Sterz [this message]
2024-11-28 14:44 ` Gabriel Goller
2024-12-03 17:11 ` [pbs-devel] applied: " 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=D5XW27OXAB6E.BUIKTFN37CK5@proxmox.com \
    --to=s.sterz@proxmox.com \
    --cc=f.ebner@proxmox.com \
    --cc=pbs-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal