DHCP settings page reloads when opened

General Beta 5.0
1

Problem with Beta 5.0:
When you go to Settings on the web interface then click the DHCP tab, the page reloads once (even though you can already see the settings right before it reloads). Is this a bug?

2

Does it happen in all browsers ?

It doesn't do it on my side ...

3

I've seen this happen on Safari for macOS and iOS, as well as Firefox beta for macOS.

4

Ah... I do see that too on my iOS device ...

While I don't know why it does this, I assume it is because initially reads the config file (the data one sees before the "refresh") and then it runs additional checks for (maybe lease files or other checks) and then puts them all together.

I will look into that.

Pinging @DL6ER maybe he ca can provide some info before I review that part of the code to see what happens ...

6

I think this was added by an external contribution to ensure the DHCP static leases are up-to-date even after a teleporter import.

edit Seems I was correct on this:
https://github.com/pi-hole/AdminLTE/pull/992/files#diff-f7ecd809af19b9fcd567a1ad79f98756

Do we need to change this?

7

I think this comment near the end of the PR sums up my thoughts on this perfectly:

I'm not sure about the page reload. Isn't there any way around it? It doesn't feel natural to me. I mean, if we are supposed to it this way we might as well not have DHCP as a tab and just as a ?

Reload settings.php after the teleporter import instead of every time the tab is opened? Is that possible, or am I misunderstanding what the reload is doing?

8

Well, yes, but not super easy. The issue here is that the teleporter is loading the content in a new tab/window from which we cannot reload the settings page in another tab. We could surely do it with local storage but that may be too much.

A compromise would be to reload the page with a fixed delay of, say, five seconds after the teleporter import was triggered, crossing the fingers that the import of the DHCP leases will be done by then.

9

Dunno if that's a good idea, as that doesn't really give certainty

I suppose that if there's no easy way to do it more invisibly to the user, then the current way is fine since it's not really a usability issue, just looks a little odd.