- This topic has 22 replies, 2 voices, and was last updated 19 hours, 17 minutes ago by
.
-
Posts
-
That is super strange. I did a bit of research and Safari seems to have a very problematic cache, it will load outdated files even if the cache is cleared.
Can you please try by opening the Web Inspector then going to the Network panel and clicking “disable cache” checkbox? If you keep the inspector open the issue should go away – which would verify the Safari cache issue.
I couldn’t replicate it on my end anymore, both Chrome and Safari works all right, so the only thing left is the aggressive browser cache.
Hi,
The issue still persists. It’s very annoying. I have to again and again adjust many the color options. You can check my screenshot record.
https://drive.google.com/file/d/15Q-Cgi3_A_oTBVKDPap4vlYs6C-MGHf4/view?usp=sharing
As you can see:
– I use new Incognite tab and also check “Disable cache” to prevent caching issue.
– You can notice that the colors were saved correctly for the initial saves. However, they were reset again unexpectedly. This wasted a significant amount of time for me to adjust the colors.Hope you can help me solve this issue quickly.
Best,
GeorgeSure George! Thank you for the video!
Interestingly I still can’t replicate it like that, I’m not sure why, both Mac and PC platforms work on my end. Nevertheless, I will do a profiling on the page source, there must be still a 3rd party conflict somewhere which I can’t see and is likely causing this problem.
I will run an AI based analysis on the scripts profile running on the page, maybe it can find the reason why – there is probably something resetting the color picker script, as everything else seems to be all right. I will also share the video of replication to speed it up.
I will let you know as soon as possible, as I am very curious what is going on here and why there is no other reports or why I can’t replicate this issue at all.
All right, the AI actually found the issue based on the source! It was a 3rd party script conflict as I suspect, but I couldn’t find the source of it.
It’s a conflict between Ajax Search Pro and your active theme (theblog). The theme’s mega-menu component loads an old color-picker library called jscolor across the entire WordPress admin. That library automatically latches onto any color input on the page ā including the ones in Ajax Search Pro’s settings ā and because it doesn’t understand our color format, it silently resets the value back to a default. This should be also addressed by the theme developer, it is highly problematic to load global assets across the whole admin interface.
The reason it only showed up after saving twice: the first save reloads the page and our picker displays correctly, but jscolor then quietly overwrites the stored value in the background. The second save commits that overwritten value, so the reset only becomes visible on the next reload. That timing is also why it was so hard to reproduce on a clean setup ā it only triggers when a theme/plugin like this is present, which is why your Mac/Safari/Chrome reports were spot on about it being a timing issue.
The fix
I’ve updated Ajax Search Pro so its color pickers can no longer be hijacked by jscolor (or any similar library), with an extra safeguard on top. This will be included in the next public release, but I’ve prepared a hotfix build for you right now: hotfix downloadI have already installed it on your staging site. Please clear the browser cache and the issue should disappear.
Hi,
Great! Thanks for finding the root cause.
I can confirm that the issue have fixed. Did you download all source code and use AI to inspect?
Best,
You are welcome!
Did you download all source code and use AI to inspect?
Not at all, don’t worry – I didn’t download the actual server side source code (like the plugin files). I only grabbed what was emmited to the browser for rendering as HTML – so a “page view”. No sensitive data, source files or anything, I would never do that š
- You must be logged in to reply to this topic.