What's new

Diversion AC Merlinware 386.14 introduces screen scrolling problem on MANY [but not all] webui add-ons!

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

kernol

Very Senior Member
There are already other threads for Skynet and YazFi addons ... however no mention as yet that Diversion's webui page is probably the most prevalent one to be hit by this problem. Here is the exact problem that affects MOST addon webui pages [with the exception so far of - scMerlin page]

386-14-b2-webui-error.png


If one manually edits out "overflow: hidden;" and leaves the rest - the page displays correctly with the scroll bar fully functional.
I am not a coder - so have no idea what generates that unwanted piece of code.

On the other hand - I have no doubt that @thelonelycoder will be able to find a fix - and also that the same fix can be applied to all the other add-on pages that don't scroll under 386.14 - The biggest impact from a scrolling point of view is on Scribe and Skynet - useless if you can't scroll 😌.

If I understand the Merlon Maestro correctly - this problem was introduced by Asus itself ... and I guess will likely find its way into future GPL releases from Asus for other models in their range??
 
There are already other threads for Skynet and YazFi addons ... however no mention as yet that Diversion's webui page is probably the most prevalent one to be hit by this problem. Here is the exact problem that affects MOST addon webui pages [with the exception so far of - scMerlin page]

View attachment 60516

If one manually edits out "overflow: hidden;" and leaves the rest - the page displays correctly with the scroll bar fully functional.
I am not a coder - so have no idea what generates that unwanted piece of code.

On the other hand - I have no doubt that @thelonelycoder will be able to find a fix - and also that the same fix can be applied to all the other add-on pages that don't scroll under 386.14 - The biggest impact from a scrolling point of view is on Scribe and Skynet - useless if you can't scroll 😌.

If I understand the Merlon Maestro correctly - this problem was introduced by Asus itself ... and I guess will likely find its way into future GPL releases from Asus for other models in their range??
I’m still far from home. I will address this when I’m back home sometime next week.
 
There are already other threads for Skynet and YazFi addons ... however no mention as yet that Diversion's webui page is probably the most prevalent one to be hit by this problem. Here is the exact problem that affects MOST addon webui pages [with the exception so far of - scMerlin page]

Just to clarify, the "missing scrollbar" issue is currently happening with the Diversion webGUI but not with the latest uiDivStats v4.0.1 release, correct?

About 3 weeks ago, I submitted a pull request for the uiDivStats add-on that addressed the compatibility issues with the 3006.102.1 F/W version, and it was merged about 2 weeks ago. That PR also fixes the issue with the latest 386.14 F/W release.

So, AFAIK, only the Diversion webGUI remains to be fixed between the two.
 
I’m still far from home. I will address this when I’m back home sometime next week.

At one point, I meant to take a look at the problem for Diversion, but I couldn't find a repository in GitHub, and then I got so busy with work and other personal "stuff" that I forgot to send you a message about it.

Is the repository for Diversion publicly available?
If not, how can I submit a pull request for it?
 
I believe the overall problem with 386.14 and addons is the use of var $j=jQuery.noConflict(); in some addon webUIs which was most likely an effort to ensure compatibility with John's fork back in the day. Removing those accommodations seems to fix the scrollbar issues in Skynet, without adding Martinski's workaround.

Specific to skynet, reverting this change seems to let the new asus_policy.js load OK without problems:

Other addons may test the same idea with jQuery.noConflict.
 
@thelonelycoder if you remove the jQuery.noConflict() statement, replace all $j( with $( and swap the order of state.js and jquery.js, I can get the Diversion webui to load properly on 386.14. No testing done on 388 or 102, however.

WebUIs are becoming a game of whack-a-mole with 3 different ASUS branches...
 
He’s called the lonely coder for a reason… :)

@thelonelycoder if you remove the jQuery.noConflict() statement, replace all $j( with $( and swap the order of state.js and jquery.js, I can get the Diversion webui to load properly on 386.14. No testing done on 388 or 102, however.

WebUIs are becoming a game of whack-a-mole with 3 different ASUS branches...
Thanks. I‘m still enjoying the balmy weather of southern Utah, Arizona Strip and Nevada 😎
 
WebUIs are becoming a game of whack-a-mole with 3 different ASUS branches...
In a few months there will be one less branch to handle...

I suspect like you pointed out that a lot of the addon UI issues come from very old legacy code that's still present. The original pages probably used these, and authors copied and reused those original pages, which explains why the same issues are now appearing in multiple addons. Personally, the only change I had to do in my own pages with the recent 3006/386 merges was to fix the order of httpApi, client_functions and jquery - I didn't need to address any scrollbar-related issue. There were also a recent upstream change where the down arrows used by the client list dropdown were replaced with SVG versions of the images. I updated my own pages for these, but the original image still works - for the time being.

Your fix is probably more on the money than the workaround implement in Skynet which forcibly changes attributes pushed by state.js (from what I gathered by a quick glance at it).

One recommendation I might make is that whenever I merge a new GPL, keep an eye on the changes I do to Tools_Sysinfo.asp or Main_WStatus_Content.asp. These are two good examples of custom pages that I will have to update from time to time to match with upstream changes. The first one is a simpler example, while the second one will also interface with client_functions.js which is one area that may experience changes over time. A lot of the breaking changes coming from upstream will be fixed by me in these two pages.
 
I suspect like you pointed out that a lot of the addon UI issues come from very old legacy code that's still present. The original pages probably used these, and authors copied and reused those original pages, which explains why the same issues are now appearing in multiple addons.
I was a big proponent back in the day for addons to be compatible with John's fork, since that is what I preferred running on my old AC68U. I don't remember now why the noConflict() was required, but I remember pushing Jack and Adamm to include it. Blame me.

EDIT:

A lot of the community effort to report/fix this issue was missing the JavaScript errors on the browser console that were definitely attributable to jQuery $. The overflow was a side-effect of the bad loading of the JavaScript.
 
Last edited:
I believe the overall problem with 386.14 and addons is the use of var $j=jQuery.noConflict(); in some addon webUIs which was most likely an effort to ensure compatibility with John's fork back in the day. Removing those accommodations seems to fix the scrollbar issues in Skynet, without adding Martinski's workaround.

Specific to skynet, reverting this change seems to let the new asus_policy.js load OK without problems:

Other addons may test the same idea with jQuery.noConflict.

That's an excellent find. I have also verified that your latest PR changes in Skynet work very well on 2 different routers: RT-AC86U (running 386.14) & RT-AX86U (running 388.8).

I was unaware of the history behind the initial "var $j = jQuery.noConflict();" changes made for the add-ons.

I'd like to point out that none of @Jack Yaz's add-ons (YazFi, uiScribe, uiDivStats, ntpMerlin, spdMerlin, connmon, etc.) have required a workaround for the "missing scrollbar" or any changes related to "var $j=jQuery.noConflict();" So far, all I have had to do to address the compatibility issues with 3006.102.1 and 386.14 F/W versions is to make sure the required JS files (/js/jquery.js, /js/httpApi.js, /client_function.js) are present or added in the correct order as previously specified by RMerlin.

Somehow, whatever "secret sauce" is used by JackYaz with his JS/ASP files, they're all working well even with the "$j=jQuery.noConflict()" code still present.
 
Somehow, whatever "secret sauce" is used by JackYaz with his JS/ASP files, they're all working well even with the "$j=jQuery.noConflict()" code still present.
Do they just work by chance or are there browser console errors present that don’t happen to break the page yet?

Interesting trivia is that Jack actually co-authored the Skynet webui.
 
Do they just work by chance or are there browser console errors present that don’t happen to break the page yet?

Here are some samples of what I get. All pretty much have similar output.


YazFi_v4.4.5_OK.jpg



scMerlin_v2.5.6_OK.jpg
 
I'd like to point out that none of @Jack Yaz's add-ons (YazFi, uiScribe, uiDivStats, ntpMerlin, spdMerlin, connmon, etc.) have required a workaround for the "missing scrollbar" or any changes related to "var $j=jQuery.noConflict();" So far, all I have had to do to address the compatibility issues with 3006.102.1 and 386.14 F/W versions is to make sure the required JS files (/js/jquery.js, /js/httpApi.js, /client_function.js) are present or added in the correct order as previously specified by RMerlin.
Fully appreciate your efforts on this hiccup - just a little puzzled by the above para. For me under 386.14 uiScribe is still broken despite fresh install - must be missing the secret sauce Jack had in scMerlin which was unaffected from the getgo.
 
Fully appreciate your efforts on this hiccup - just a little puzzled by the above para. For me under 386.14 uiScribe is still broken despite fresh install - must be missing the secret sauce Jack had in scMerlin which was unaffected from the getgo.
When I implemented the fix and tested it before submitting the PR, I had no issues with my RT-AC86U running the latest 386.14 F/W.

uiScribe_v1.4.6_OK.jpg


Keep in mind that you *must* update to the latest 1.4.6 version from the 'develop' branch:
Bash:
/jffs/scripts/uiScribe develop
/jffs/scripts/uiScribe forceupdate

If you still have issues, grab some screenshots, including the browser console window to see what or where the problem might be.
 
Last edited:
For me under 386.14 uiScribe is still broken despite fresh install
Fresh install of what/which uniScribe version? The uiScribe develop version (v1.4.6), or the main stable version (v1.4.5)? Make sure to use the develop version:
Code:
/jffs/scripts/uiScribe develop
/jffs/scripts/uiScribe forceupdate
 
Last edited:

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top