Project

General

Profile

Actions

Bug #7028

closed

Squid - all javascript broken by bootstrap conversion

Added by Kill Bill over 7 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
Squid
Target version:
-
Start date:
12/21/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
2.3.x
Affected Plus Version:
Affected Architecture:
All

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.

Actions #1

Updated by Anonymous over 7 years ago

And a merry frickin' Christmas to you too :)

Looking at this now.

Actions #2

Updated by Kill Bill over 7 years ago

Thanks. Yours truly Santa. :-P

Actions #3

Updated by Anonymous over 7 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

Actions #4

Updated by Kill Bill over 7 years ago

Thanks, much appreciated! Will test with a new snapshot ASAP.

Actions #5

Updated by Anonymous over 7 years ago

Remember to update BOTH Squid from the package manager, AND the base system from the Update manager.

Actions #6

Updated by Kill Bill over 7 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?

Actions #7

Updated by Anonymous over 7 years ago

Should be there already

Actions #8

Updated by Kill Bill over 7 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.

Actions #9

Updated by Anonymous over 7 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.

Actions #10

Updated by Kill Bill over 7 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?

Actions #11

Updated by Anonymous over 7 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

Actions #12

Updated by Kill Bill over 7 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.

Actions #13

Updated by Anonymous over 7 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.

Actions #14

Updated by Kill Bill over 7 years ago

Yeah, 0.4.28 behaves like it used to works on pfSense 2.2.x, all weirdness gone. Very cool. Thanks!!!

Actions #15

Updated by Anonymous over 7 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Kill Bill to Anonymous
Actions #16

Updated by Luiz Gustavo S. Costa over 7 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.

Actions #17

Updated by Kill Bill over 7 years ago

None of those fixes are in 2.3.2 so it's just pointless to test anything there.

Actions #18

Updated by Anonymous over 7 years ago

Right. It is not "A new bug", it is the original bug that has just been fixed.

Actions #19

Updated by Luiz Gustavo S. Costa over 7 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

Actions

Also available in: Atom PDF