FIREFLY-1744: Fix ADQL color mode bug in Job Monitor dialog

[kpuriIpac]

Ticket: https://jira.ipac.caltech.edu/browse/FIREFLY-1744

• The main reason for this bug is that DialogRootContainer is essentially a separate root (from the main FireflyRoot)
• So when toggling theme, a re-render would not occur inside dialogs
  • But the rest of the dialog (except ADQL block) would still manage the theme change, because most of the dialog UI uses global Joy UI CSS
    • The ADQL block, though, uses Prism whose theme is injected via CSS strings, so it required an explicit re-render
      • the code changes in AppConfigDrawer and DialogRootContainer take care of this, forcing a re-render of the dialog on theme change
• Even after the re-render of the dialog, useColorMode() in CssStrThemeWrapper would still not give the correct theme for the dialog (because dialogs are rendered in a separate React root with their own Joy CssVarsProvider)
  • This led to relying on getting the Joy scheme from the DOM in the case of dialogs (with ADQL block) specifically

Eventually, this PR could be made redundant if dialogs were not in a separate React Tree. We plan on discussing this change January 27-28.

Testing:
Firefly: https://fireflydev.ipac.caltech.edu/firefly-1744-adql-toggle-bug/firefly

• test toggling dark to light mode and vice-versa upon opening a TAP Job Info dialog from the Job Monitor (described in ticket above)
  • ensure the ADQL block changes to dark/light mode as expected when you toggle the theme
• test toggling dark to light mode and vice-versa on the Edit ADQL page (regression testing)

[jaladh-singhal]

Tested! Working as expected.

I think it's good as an intermediate fix/workaround.

[jaladh-singhal]

I wonder if it's possible to directly pass this color mode (newValue) to dialog root here (like setMode/useMode does for firefly root) which would have prevented reading scheme from DOM.

[kpuriIpac]

@jaladh-singhal I made a new commit that sort of follows this feedback. Can you take a look? I do think it's cleaner (I'll get rid of the commented out code if we decide to keep this change):

• essentially, refreshDialogs(newValue) forces the dialog root to re-render.
• The key in FireflyRoot (in reRender) forces a remount of FireflyRoot in the dialog root (which was previously missing, only the main (non-dialog) FireflyRoot was re-rendering, which is why useColorMode inside CssStrThemeWrapper would not give the right value for dialogs).
  • with this change, we don't need to make any changes in PrismADQLAware or CssStrThemeWrapper at all.

Let me know what you think.

[jaladh-singhal]

Thanks for trying it out. It is def cleaner now. About the key, shouldn't that be in DialogRootComponent instead of FireflyRoot? I'm not sure about this though.

[kpuriIpac]

Yes I think it needs be inside FireflyRoot because really the CssVarsProvider inside FireflyRoot is what needs to remount/re-render..for us to get the correct value from useColorMode (in CssStrThemeWrapper). I did try putting the key in DialogRootComponent, though, and that did not work...I'm guessing for this reason.

[loitly]

This is a reusable component that supports color mode changes. Without useColorMode, it would stop working entirely, so it can’t be commented out. I’m not sure if it’s related, but TAP → Edit ADQL is now broken.

[kpuriIpac]

Yes @loitly I am keeping the useColorMode() (it's above this commented out code) because I know CssStrThemeWrapper is used elsewhere (AdvancedADQL). Is Tap -> Edit ADQL broken only on my test build above? or do you see it broken on nightly too? if it's the former, then I'll have to look into it...

[kpuriIpac]

Never mind, the bug with ADQL was in my code. Fixed in a new 1 line commit and re-building test build. But rest of what I wrote up here still holds (about useColorMode()).

[jaladh-singhal]

preferDomScheme is no longer in use, I think this whole file can be reverted as well as AdvancedADQL

[jaladh-singhal]

@kpuriIpac your build is no longer accessible to me but I trust your testing 😄 and it's ready to merge after removing dead code imo (esp because it's an intermediate fix)

[kpuriIpac]

@kpuriIpac your build is no longer accessible to me but I trust your testing 😄 and it's ready to merge after removing dead code imo (esp because it's an intermediate fix)

okay thank you for looking at it again! I'm rebuilding the test build after cleanup and will merge then if I find no issues.

And yes I agree this is at best an intermediate fix, the good thing is that the reRender call that I added only happens when you change the theme while a dialog is open...but If we implement the architectural change of moving dialogs into React Portal (instead of a separate root) this year, that'll be the best solution.