Hiding the Browse by Category Section

Alex_Marsh

So after seeing this https://community.cireson.com/discussion/4012 and being able to reorder the catalog listing page how the customer wanted it, they then wanted to hide the "Browse by Category" section. Simples I thought, find the section with js and hide it.

This is what I put in for them

$('h4:contains("Browse By Category")').parent().hide()

But alas, it works fine in all browsers, and on server versions of IE but not IE 11 on a Windows 10 client. When clicking on a link which takes the user to the service offering, the entire portal fails to load

Any ideas why this tiny piece of code would cause this? It also only happens intermittently just to add further confusion

Tom_Hendricks

Are you using the /ServiceCatalog/Listing/ view of the catalog?  Hiding this works flawlessly using your code, pasted into the browser console.  That leads me to think that maybe something else, such as the timing, is causing the issue.

Do you have any mutation observers, or do you use setInterval to control when this statement occurs?  I obviously have no idea, but it seems as though there might be an error with one of those or the lack thereof might be causing your statement to run before the page is fully laid out.

You may have already thought of this, but if not I hope it helps.

Alex_Marsh

Tom_Hendricks said:

Are you using the /ServiceCatalog/Listing/ view of the catalog?  Hiding this works flawlessly using your code, pasted into the browser console.  That leads me to think that maybe something else, such as the timing, is causing the issue.

Do you have any mutation observers, or do you use setInterval to control when this statement occurs?  I obviously have no idea, but it seems as though there might be an error with one of those or the lack thereof might be causing your statement to run before the page is fully laid out.

You may have already thought of this, but if not I hope it helps.

That was my initial thought. I added the code into the mutation observer script for rearranging the page above and it runs without issue everywhere but some windows 10 clients. Doesn't seem to matter where I put it (document ready script, element loaded) it causes the entire portal to fail to load when clicking a RO which directs to a SO in IE 11.

This is the current script with the hiding commented out due to the above issue. It's being called with loadscript function on ServiceCatalog/Listing

$(document).ready(function () {

    var mainPageNode = document.getElementById('main_wrapper');
        
    // create an observer instance
    var observer = new MutationObserver(function(mutations) {
			
		
		//$('h4:contains("Browse By Category")').parent().hide()
		//$('.ng-scope').width("96%")
        
		/*var rolist = $('h4:contains("Browse By Category")')
		if (rolist.length > 0) {
			$('h4:contains("Browse By Category")').parent().hide()
		}*/
		
		
        //The page changed. See if our element exists.
        var formElement = $('.sc__home-kb-lists')
                
        if (formElement.length > 0) { //An element exists.
        
            $('.sc__home-kb-lists').appendTo($('.sc__home'))
						
			$(".sc__header").append('<p></p><p class = "newhome">Welcome to ICT Service Desk Portal.</p><p class = "newhome">You can use this Self Service Portal to register service requests, record incidents, read self-help guides and order IT kit such as computers, accessories and software.</p><p class = "newhome">To find what you are looking for, type a keyword into the search box below - e.g. "Password", "Email". Alternatively please scroll down through the menu below to choose from the full list of requests.</p><p class = "newhome">Click <a href="https://itsupport.ealing.gov.uk/KnowledgeBase/View/125#/"><u>here</u></a> for the Service Portal User Guide.</p>')
            
            //We are done observing.
            observer.disconnect();
        }
    });
    
    // configure the observer and start the instance.
    var observerConfig = { attributes: true, childList: true, subtree: true, characterData: true };
    observer.observe(mainPageNode, observerConfig);
});

Tom_Hendricks

The only thing that strikes me as odd is that your commented-out block of code is not inside an IF statement.  That means that it will run on every single mutation to the page, of which I assume there will be many before the .disconnect() is triggered.

I unfortunately don't have time to drop this in and test it, but I suspect that wrapping your "hide" code in some kind of test to ensure that it only runs once may be the way to fix this.  Given that you are testing for the presence of a completely different element below, you could use a second observer (so that it can be disconnected on its own terms).  I thought briefly of modifying your IF or just adding a second one, but that might cause more of a visual delay, potentially (since both elements would need to be present.  It would solve the problem of running more than once, though.

Without actual testing, these are just thoughts, of course, but I hope they help.

Alex_Marsh

The loadscript function ensures that it only runs on a specified page so it will only check on pages with servicecatalog/listing in the address (which is where we want it to run).

As a further test I did have it outside of a mutation observer (document.ready) and it did the same thing.

It's the whole only client IE which is throwing me! 

Tom_Hendricks

I think having it outside of any mutation observer would have a different problem, which would be running before the elements are there to be modified.

The solution to this is obviously to purge IE from the environment with extreme prejudice and ban its use going forward, but I doubt that is an option since you haven't already done it. 

Technically JQuery is taking care of the test to see if the element exists for you, so you could use that to your advantage.  If you haven't already tried this (not sure from your reply), you could try something like this in document.ready():

$(document).ready(function () {
    var hideStuff = setInterval(function () {
        var categoryElement = $('h4:contains("Browse By Category")');
        if (categoryElement.length > 0) {
            clearInterval(hideStuff);
            categoryElement.parent().hide();
	    $('.ng-scope').width("96%");
            var rolist = $('h4:contains("Browse By Category")');
	    if (rolist.length > 0) {
	        $('h4:contains("Browse By Category")').parent().hide()
	    }
        }
        else {
          hideStuff();  
        }
    },50);
    
    // Put your other mutation observer here
});

This all assumes that the issue has something to do with timing and trying to handle this within the other mutation observer.  You could replace this with another mutation observer to accomplish the same thing instead of setInterval, of course.  If timing and/or running this code too often inside the other observer is not the issue, then this will only serve to rule it out.

If that is the case, then I wonder if something else unrelated is running that is interfering (perhaps erroring out, stopping script execution?).  IE is absolutely terrible for debugging compared to its peers, so it would not be difficult to miss this (another reason to eradicate it!).

Alex_Marsh

Yeah I'm getting to the point where it's going to be put down as just a general IE bug (though it still perplexes me how I can't recreate this on a Server 2012 R2 version of IE.

As it happens (it would appear that the customer didn't want to do any significant debugging on their IE to work out why this is occurring) the hiding of the content browser has been removed from their requirements but I'm going to have a bit more of a play with the above when I've got some further time to see why this issue arises.

Tom_Hendricks

Since I can't reproduce this in Win10 IE (granted, I am not running any of their other code, so this is not a great comparison), I wonder if they might have add-ins/extensions running that are interfering with it.  I am aware of a few that actually modify the DOM.  If true, I'm sure they would resist disabling them, of course.