From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 6072F1FF16B for ; Thu, 28 Nov 2024 15:41:48 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 951E68CF2; Thu, 28 Nov 2024 15:41:49 +0100 (CET) Mime-Version: 1.0 Date: Thu, 28 Nov 2024 15:41:09 +0100 Message-Id: From: "Shannon Sterz" To: "Fiona Ebner" , "Proxmox Backup Server development discussion" X-Mailer: aerc 0.18.2-0-ge037c095a049-dirty References: <20241128134925.196856-1-s.sterz@proxmox.com> <2a4b6b22-09a3-473a-ba37-fe30ae865e8a@proxmox.com> In-Reply-To: <2a4b6b22-09a3-473a-ba37-fe30ae865e8a@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.039 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup] ui: check that store is set before trying to select in GCJobView X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Backup Server development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" 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 > > --- > > 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