asked on

location.href being assigned about:blank in chrome 34

Hello Experts,
For whatever reason I am getting about:blank assigned to my object bill.location.href.

Below is the code Attached are the results in the chrome console. This worked fine prior to the update to chrome 34.

Any help will be appreciated.

PopulateTab: function (tabHandle, actionUrl, treeQuery) {
        var treeUrl;
        if (actionUrl.substr(0, 7) == "http://" || actionUrl.substr(0, 8) == "https://") {
            treeUrl = "blank.html";
        }
        else {
            treeUrl = "Tree.aspx?AppID=5004&treestate=" + treeQuery;
        }
        try {
            //  this.GetTabActionFrame().location.href = actionUrl; 
            var bill = this.GetTabActionFrame()
            bill.location.href = actionUrl;
       //    this.GetTabActionFrame().location.href = encodeAmpersandInUrl(actionUrl);
        } catch (e) {
            console.log('in poptab');
            console.log(e.stack);
        }
    },

 GetTabActionFrame: function (tabName) {
        if (!tabName) {
            tabName = this.GetSelectedTabName();
        }
        var iFrame = $("#action-" + tabName).get(0);
        var value;
        if (iFrame) {
            value = iFrame.contentWindow;
        }
        return value;
    },

Open in new window

Julian Hansen

And if you change

bill.location.href to bill.location?

Michel Plungjan

And

bill.location.href = treeUrl;

bill_home

ASKER

HJello JulianH and mplungjan,

Location did not work, treeUrl is not what I want to do here: This worked, anyone who can tell me why gets the points. ( I changed the var name from bill to tabActionFrame).

var tabActionFrame = this.GetTabActionFrame();
setTimeout(function () { tabActionFrame.location.href = encodeAmpersandInUrl(actionUrl); }, 500);

Julian Hansen

Is that the fact that you changed the var name from bill to tabActionFrame or the fact that you waited 500ms before assigning the location that did the trick?

bill_home

ASKER

waited for 500ms did the trick...

ASKER CERTIFIED SOLUTION

Julian Hansen

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

bill_home

ASKER

very willing to work with me to get a solution.

Member_2_248744

greetings bill_home, since you say - "worked fine prior to the update to chrome 34", and you later say that "waited for 500ms did the trick", , I will give you my opinion about why, a while back , I had to use some slow downs like -
setTimeout(function () { tr1 = changeDiv('div1')}, 200);

Because if I did NOT use the setTimeout( ) then it would NOT work because The page DOM would not yet recognize the New Div I just added as ID 'div1' in JS code, but if I gave the page DOM 100 or 200 ms, then the page DOM would have finished cultivating the new DIV, and a valid reference for ID 'div1' would exist.

I would think that in the new chrome 34, they made some JS implementation faster, so your old code (without the setTimeout ) needed a reference of some sort from a newly created resource, and in older this was there, in newer 34 (maybe faster, maybe slower) the needed reference was not there (a URL it appears) so it goes to the default about page. Not sure about what the encodeAmpersandInUrl( ) does, or is a factor here.

You may not can gain any useful code know how from what I have said, and it's just an opinion, but it is likely this new error for 34 has affected other JS writers, and may be in a web search or two for problems wid chrome 34.