Bug when moving feature blocks

Configuration
1

Hello,

I’m using Firefox 114.0.1 on Linux.

If I create a device block and drag it, visually it glitches even though it works if I click save.

Screenshot_20230617_152722
Screenshot_20230617_1527221280×921 152 KB

I created block 1.
I dragged it onto block 2.
and it looks like this:
Screenshot_20230617_152752
Screenshot_20230617_1527521280×921 150 KB

The block name is OK but its content copied that of its destination (or at least that of another block).

2

I also had a conflict like that, even after merging the two blocks but without saving, if I remember correctly on my phone.
I tried again on a PC (Chrome) and then it worked.

3

Thanks for the feedback @Hizo :slight_smile:

@Lokkye I don’t know if you’ve seen this bug. Apparently the new « Devices » widget doesn’t seem to support this behavior, we should check whether the « componentWillReceiveProps » function is present and working properly

I’ve created a GitHub issue:

4

Ah, I’ll take a quick look at that.

1 Like
5

Sorry but I can’t reproduce it on my end in Chrome and Firefox :frowning:

6

@Lokkye have you tried moving a Device box onto another? I think it’s only the « React-Select » part that disappears.

7

@pierre-gilles: Yes, I’ve tried lots of things, putting one box on top of another, underneath, above, in another column. I don’t see any problem on my end :frowning:

8

I just ran the tests again; it also happens with the « Room devices » block.

And when I try to move the block up within the same column, there is no visual change even though it’s OK once saved.

And when I move the block to another column, visually (only), its content changes…

The same thing happens to me with Opera v100.0.4815.20.

9

The bug occurs 100% of the time on my end:

  1. I drag and drop a « devices » widget onto another « devices » widget (different title, and different selected devices)

  2. The source widget disappears (in the display) for the selected devices:

10

A message was split into a new topic: Question about moving scene actions

11

@pierre-gilles okay I just realized that locally (dev env) I don’t have the problem. But on my remote instance I do have the problem :frowning: . I’m looking into where this could be coming from

12

@pierre-gilles : Well, you were right about the function « componentWillReceiveProps »
The PR with the fix :

1 Like
13

@Lokkye your solution is a bit heavy-handed :stuck_out_tongue: it triggers an API call for the slightest change in props, even if it’s just a simple character change in the title.

can you add a test to only refresh when necessary?

14

@pierre-gilles: My bad :frowning: It’s true that it was a bit harsh. I’ve made the change accordingly.

15

It’s better, but the problem is the same!

Do the test: add a console.log in componentWillReceiveProps, and change, for example, the widget’s name — you’ll see that the function is called for every character typed, which will call the « refreshSelectedOptions » function on every letter.

You should add an if in componentWillReceiveProps to only refresh the selection when the selection actually changes :slight_smile:

16

@pierre-gilles : I added the appropriate test :slight_smile:

17

@Lokkye Are you sure? I don’t see anything else in the PR

The goal of the test is to only re-create the array in the states if the array passed via props has changed

18

@pierre-gilles : Yes :frowning: I had forgotten to push :frowning:
Normally you should see the changes now.

1 Like
19

Thanks! I’ve just left you a review, sorry it’s a bit late — I have a lot going on at the moment on my end :slight_smile:

The check won’t work if you delete a widget and the adjacent widget has exactly the same number of deviceFeatures, it won’t refresh the list (we’re back to the original bug):