Bug #7028
closedSquid - all javascript broken by bootstrap conversion
0%
Description
Guys, there's this squid_js.inc
thing that used to do a lot of useful GUI work. It's completely no-op since the bootstrap conversion.
Unable to fix, unless some bootstrap guy steps up with some hints at least, this will probably remain perpetually broken. Sending sbeaver's way for now. ;)
Affected areas:
- Services > Squid Proxy Server > Authentication: this is badly confusing as it is, as the JS used to toggle fields so that only relevant ones were enabled according to the authentication method selected
- Services > Squid Proxy Server > Antivirus - all the Enable Manual Configuration stuff. On toggling state, it used to either preload or unset the stuff from config.xml, again no longer works.
Updated by Anonymous almost 8 years ago
And a merry frickin' Christmas to you too :)
Looking at this now.
Updated by Anonymous almost 8 years ago
- Status changed from New to Feedback
- Assignee changed from Anonymous to Kill Bill
There were two issues: There was a bug in pkg_edit.php that was causing the \<onchange\> XML tag to be rendered incorrectly, and all of the Javascript in squid_js.inc was obsolete because the Bootstrap DOM does not match the old DOM.
Bug was fixed and the Javascript replaced with jQuery. Seems to test OK, but there was a lot of typing involved!
Squid version bumped to 0.4.27
Updated by Kill Bill almost 8 years ago
Thanks, much appreciated! Will test with a new snapshot ASAP.
Updated by Anonymous almost 8 years ago
Remember to update BOTH Squid from the package manager, AND the base system from the Update manager.
Updated by Kill Bill almost 8 years ago
Steve Beaver wrote:
There was a bug in pkg_edit.php that was causing the \<onchange\> XML tag to be rendered incorrectly,
Can we get this to RELENG_2_3 please?
Updated by Kill Bill almost 8 years ago
OK, tested. The authentication tab works great. The antivirus stuff is quirky, will need to play with it. Most issues seem to be due to the advancedfield thing.
On a quick look at pkg_edit.php, there are probably quite a few more bugs, for instance, no idea what's this supposed to do:
- https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/pkg_edit.php#L1112
- https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/pkg_edit.php#L1296
I'd say it should be if ($grouping)
like everywhere else.
Updated by Anonymous almost 8 years ago
Yep. Revised that yesterday. The Antivirus stuff appears to work as designed, but that design may not be ideal. It's confusing when JS disables/enables fields that are currently hidden.
Updated by Kill Bill almost 8 years ago
Steve Beaver wrote:
Yep. Revised that yesterday. The Antivirus stuff appears to work as designed, but that design may not be ideal. It's confusing when JS disables/enables fields that are currently hidden.
Well the good think is that it appears to clear the advanced config now on save when you switch it to disabled (which was broken before your fixes.) Getting rid of the 'advanced' tags in XML got rid of the weird behaviour, except that I'd need an "onload" (not onchange) function that would keep the advanced fields disabled when you load the tab when "Enable Manual Configuration" is disabled. Is that somehow doable with XML?
Updated by Anonymous almost 8 years ago
I think that happens now. The XML fragment
<custom_php_after_form_command> squid_print_antivirus_advanced_config2(); </custom_php_after_form_command>
Sets the enable/disable state based on the selector setting, and it seems to work for me
Updated by Kill Bill almost 8 years ago
Well, that's kinda difficult to see with the package as is. :) What I did for testing was nuking all the "advanced" tag stuff in the XML. After that, all the advanced fields are visible all the time and yes, you can see they get toggled with Enable/Disable changes. But when you initially load the tab with Enable Manual Configuration set to Disabled, the raw config textarea fields are not disabled.
Updated by Anonymous almost 8 years ago
Can you describe"the weird behaviour" please? I don't see anything untoward. Also what Browser/OS are you using?
The
<custom_php_after_form_command> squid_print_antivirus_advanced_config2(); </custom_php_after_form_command>
Thing was not working because it was being executed before the page had finished loading. I have fixed that and bumped Squid to 0.4.28 The form elements are now properly enabled/disabled on page load.
Updated by Kill Bill almost 8 years ago
Yeah, 0.4.28 behaves like it used to works on pfSense 2.2.x, all weirdness gone. Very cool. Thanks!!!
Updated by Anonymous almost 8 years ago
- Status changed from Feedback to Resolved
- Assignee changed from Kill Bill to Anonymous
Updated by Luiz Gustavo S. Costa almost 8 years ago
A new bug is revelead, see:
The syntax is duplicated.
New installation from 2.3.2 version with last package version from Squid.
Updated by Kill Bill almost 8 years ago
None of those fixes are in 2.3.2 so it's just pointless to test anything there.
Updated by Anonymous almost 8 years ago
Right. It is not "A new bug", it is the original bug that has just been fixed.
Updated by Luiz Gustavo S. Costa almost 8 years ago
Steve Beaver wrote:
Right. It is not "A new bug", it is the original bug that has just been fixed.
https://github.com/pfsense/pfsense/commit/a038b8166a332579112f52639fd5ac03b5f76565