In today's beta 2.6 I found another component with the same sort of error that TWebRadioGroup had in the previous beta 2.6. This error appeared upon restarting IDE after setting Web Designer = True:
Also, the main form CSS Library was changed from cssBootstrap when Web Designer was False to cssNone when loaded with Web Designer = True
We fixed the issue with ElementLegendClassName. Next update will have this fix.
I could not reproduce a problem with CSSLibrary. Can you please provide exact steps / sample source project?
OK, here's the recipe for the form property change.
With our latest internal build, this opens & runs without any issue.
I suggest to monitor this group for the announcement when we updated the beta and then try with the update.
??? I saw today that the posted v2.6 BETA (1,450.26 MB) had a different size than previously so I downloaded and installed it, after uninstalling the previous one. It did not show the popup error in step #3 of my above recipe, but it still presented the two breakpoints upon running in Debug mode and the CSSLibrary was again changed to cssNone after the run.
I guess you refer to breakpoints in the browser? If so, these must have been cached breakpoints. Delete these from the browser console and/or clear the browser cache.
Please provide exact steps for seeing the CSSLibrary issue as I cannot see such problem here.
Bruno, I have not inserted any breakpoints, browser or otherwise, in this project AFAIK. I tried "Empty Cache and Hard Reload" from Chrome's menu with Dev Options showing and that indeed prevents the breakpoints from occurring in that run, but they are back in the next run. These breakpoints continue to occur in every run using Chrome or Edge browser choice, but do not appear in FireFox Developer Edition.
Following my above recipe steps 1-5 with the BootstrapDoodle.zip project that I uploaded to this thread always results in CSSLibrary=cssNone with yesterday's v2.6 BETA (1,450.26 MB) on my system. If I then change CSSLibrary back to cssBootstrap and run a second time, CSSLibrary does not revert to cssNone.
P.S.: I always use Holger's suggestion of running the IDE in DPI Unaware mode, but I just tested using the normal mode and found the same behavior w.r.t. the change in CSSLibrary and the stray breakpoints in Chrome/Edge so that's not relevant to my recipe.
Regarding 1 & 2: You have to use the virgin project to see the CSSLibrary change! If you've saved the project from the IDE with WebDesigner=True it won't then revert to cssNone. EDIT: I just tried this for the first time and discovered that the saved project also reverts to cssNone on its first run after reloading it. Clearly there is a difference between our IDEs. I'll try reinstalling the Beta today.
Regarding 3: I haven't tried running it after loading and saving the then no-longer virgin project, but if you're rerunning the saved project that may be why you don't see the breakpoints. I'll explore that and report later.
I open your project you attached here and I follow your steps and I can not see any of these issues. What can I do more?
If the problem happens in other circumstances, then provide details about these circumstances.
To begin with, it would be good if you could test something on another machine first before submitting a problem report
I re-installed the Beta that I had downloaded on 14Aug. This time I installed to both D11 and D12. The D12 installation is behaving the same as before and the D11 installation does the same. I'm in the process of installing D12 and the 14Aug TMS Web Core Beta on a Win11 Insiders Edition VM, which needs some updates first so it will take some time. I'll post again when that test is done.
N.B.: The CSSLibrary change and the breakpoints are specific to the posted test project. AFAIK, my other WebCore projects do not exhibit these artifacts.
Whew! I finally got the VM updated and D12.1 installed...and the WebCore 14Aug Beta too. Then I had the same issue with having to locate the WebView2Loader_x86.dll and manually copy it to C:\Windows\SysWOW64 before Web Designer would work.
After all that...BootstrapDoodle loaded and ran without issues. So...what is the incompatibility that lurks in D11 and 12.1 on my Dev system? Do you think that it's one of the other IDE addins (of which there are none on the VM setup so far)? I guess I'll have to install those one by one to find out.
I can only suspect that you do not have a really clean install of the latest beta on your other machine. Please do a FULL uninstall (via Windows Control Panel). Verify after uninstall that in the Delphi IDE no more traces of TMS WEB Core are found (see Component / Install Packages & library path).
After verifying, do a clean install of the latest beta.
I thought that you might be right about the uninstall's being incomplete because after I did the Windows App uninstall, the IDE still showed Web Core 2.6.0.0 in the startup list and the Component list still showed the 3 TMS Web Core items with checkmarks. I then found that the IDE would crash if I tried to remove them...until I had closed the Web Core project that had been open!
So, after close all and exiting the IDE, I again uninstalled the beta (which I had by then re-installed) and it no longer appeared in the IDE startup splash and the Web Core items were gone from the Component list.
Then I again installed the beta.... With Web Designer=true and Configuration=debug the behavior of BootstrapDoodle was the same as before: 2 breakpoints and CSSLibrary=cssNone after the first run.
In short: no joy, there must be some other variable.
I’m out of ideas.
I did find out how to make the breakpoints not appear: you have to clear the browser checkbox for "pause on caught exceptions". Perhaps you have that cleared even in debug configuration?
Also, I must have made the mistake of running BootstrapDoodle with Web Designer=false on the clean VM the other day when CSSLibrary did not get changed to cssNone, as today that's happening there too.
I give up. I'm going to set Web Designer=false. 
EDIT: the breakpoints happen on my Dev system even with the checkbox cleared. It's on the VM where that makes a difference. Here's what I see on the Dev system now:
So somehow that "intended" exception is causing the break even though it's no supposed to. Does this give you any new ideas?
I went back to Version 2.5.4.0 and found that BootstrapDoodle runs with no breakpoints (as well as no change in CSSLibrary) even if I set the Chrome checkbox to "pause on caught exceptions". I conclude from that that the beta has a new "intended" exception in TCustomForm.CreateControl and that's somehow related to these unintended breakpoints and perhaps to the CSSLibrary altering.
Well, I can't see any of these issues after numerous attempts. I can't see how we could have somehow created a breakpoint in our framework source code.
Do you see problems in any of our demos? Perhaps this is something in your project settings. You might try to create a new project and add the units into this new project and check.
I'm testing 2.6.0.0 only on the VM system now.
The breakpoints are not occurring in either Chrome or Edge if the "pause on caught exception" checkbox is cleared. With Edge, the expected breakpoints occur in TCustomForm.CreateControl if that checkbox is ticked, but they do not occur with Chrome until the "refresh" circle is clicked after the page has already been rendered. I imagine that is because the state of that checkbox is not read by Chrome on the initial page load, but is honored then by Edge.
I've been doing some tests of Form1.CSSLibrary property behavior with TMSWeb_Bootstrap.dproj. I'm getting different results with Web Designer=True/False. The behavior of with it False is as expected: it's cssBootstrap upon opening and does not change after running. With Web Designer=True, the behavior is not so clear and I haven't yet sorted it out. I'm in the process of making sure of a clean re-installation of 2.6.0.0 to see if things will clear up.
