I've got two JS functions, one that is adding options to a select box
function addOption(selectId, text, value) {
var selectbox = document.getElementById(selectId);
var optNew = document.createElement('option');
optNew.text = text;
optNew.value = value;
try {
selectbox.add(optNew, null); //page position resets after this
}
catch(ex) {
selectbox.add(optNew);
}
}
and another that is doing a document.getElementById(formId).appendChild(newHiddenInput) in a similarly simple function.
They both work, elements are added as expected. However, upon calling either of them, the page resets its scroll position to the top of the page in both IE6 and FF. There is no postback, this is purely clientside manipulation. I've set breakpoints in Firebug, and it occurs immediately after the element.appendChild or select.add gets executed. I know I can use JS to manually set a scroll position, but I didn't think it was necessary when the page isn't being re-rendered.
I'm no expert with JS or the DOM, so I may very well be missing something, but I've looked here and ran through their examples with the Try it Here options and I can't replicate the problem, indicating the codebase I'm working with is the culprit.
Any ideas why the scroll position is being reset? jQuery is available to me as well, if it provides a better alternative.
If the functions are being called from a link you might have an internal anchor in your link:
http://www.website.com/page.html#
This is causing said behavior. The default behavior is that if an anchor does not exist, the page scroll position jumps to the top (scrollTop = 0).
If this happens on every function call regardless of the source, then this can be crossed off the list.
What is activating the event?
If it's an anchor then on the click event you need to "return false;" after the call to your jQuery/Ajax/jScript code.
If it's a button you may need to do the same.
I had this issue yesterday and this was the resolution.
So My link
Related
How do I determine the state of a textarea element (:focus, :hover, etc.) in Chrome?
For context, I'm trying to create a web application. After submitting the form on a previous page, the textarea of the new page automatically has the cursor, which I do not want to happen. I've tried to use the jQuery code below, which works in Firefox but not in Chrome:
element = $("#elementID");
if (element.is(":focus")) {
element.blur();
}
In Chrome, the code does not execute the element.blur() in the if statement (meaning the if statement fails). I've checked with a debugger and the element is successfully returned by the id in Chrome. So I think the problem is the state check statement.
I assume the problem is the element state and I want to investigate the element state at that time, preferably using Chrome developer tools. Unfortunately, I can't figure out how to check the current state. I can only figure out how to check if the state is equal to a specific state.
I've searched around but I am only finding answers like set :hover state which discuss how to set a specific state using Chrome dev tools and not how to determine the current state when it could be any state.
I realize that I could check for each possible state at that point in the JavaScript, but it seems like I am missing the correct way to check the state.
Here is a JSFiddle of my specific case. However, I'd be interested to also hear the answer to the general question about determining the current state of a textarea.
Thanks for the help!
It's most likely an order of operations issue - the logic is executed before the input's focus can be detected.
I've reproduced the issue here, and fixed it by putting the code into the window .load() event.
var $el = $('textarea');
// will not execute
if ($el.is(':focus')) {
$el.blur();
console.log('outside of window load');
}
// will execute
$(window).load(function() {
if ($el.is(':focus')) {
$el.blur();
console.log('inside window load');
}
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<textarea autofocus></textarea>
I have a need for using the actions.mouseMove() fuction to hover over a reactive dropdown element. After doing so and clicking the elemen, that reactive dropdown persists so I now need to find someway to move the mouse away from the hover box. I do this by including a return browser.actions().mouseDown().perform() after I click my link. Here is my full function
this.changeCurrentClient = function() {
var profile = $('[id="hdr-profile-wrapper"]');
var changeClient = element(by.buttonText('Change Client'));
browser.actions().mouseMove(profile).perform();
changeClient.click();
return browser.actions().mouseDown().perform();
};
This works fine, however the problem is that when I run this on the grid, it sometimes does not properly do the moveDown() function to break out of the hover menu. I assume this is because it runs a bit slower on the grid and the DOM takes a bit longer to load. Is there a better way to break out of this rather than refreshing or doing a hard wait?
I have tried implicitly waiting for another element on the page outside of the hover menu before doing the mouseDown(), however it seems like that first action.perform() pretty much isolates you to that hover menu, so no other elements outside of the hover menu can be found. Is a refresh really the only way to do this?
I am using plupload 1.5.7. I have two buttons on page:
First one (Add new attachment) was used as browse_button in plupload configuration. When I click it, it doesn't work. Click event is executed, but file browser is not opened. But there is second button (Trigger add new attachment click), which only does this:
$('#TriggerAddNewAttachmentClickButton').click(function() {
$("#AddNewAttachmentButton").click();
})
So it only triggers click of the first button. It works fine. Clicking it opens file browser.
How is this possible? This behavior is consistent between Firefox, Chrome and Internet Explorer.
Obviously this is security related, because plupload uses tricks to hide input, but second method is not safer. I can't reproduce this issue in jsfiddle, it exists only in specific context, but maybe there is someone, who ecountered similar behaviour.
I got a similar issue with plupload. I digged into this issue for hours, and finally I find the reason. As #jbl said:
I guess I remember I had this kind of problem when the container was not visible upon plupload initialization. Could it be the same problem ?
The way of plupload working is as following:
Remember you need to set a browse_button? Actually the plupload will create an input[type="file"] for each browse_button. In normal situation, the size and position of the input[type="file"] will be the same with the browse_button exactly. So when you click the browse_button, it's not the button trigger a file chooser dialog popping up, it's the input[type="file"].
But when you set the browse_button container something like: display:none(we say, inactive), and after that even you set back the display:block(we say, active), the width and height of the input[type="file"]'s parent container would be zero some time.
My quick fix solution for this issue is as following:
I measure the position and size of the browse_button when change the state of the container from inactive to active. Then I'll manually set the position and size to the hidden input[type="file"];
Following is some sample code:
var $btn = $currPanel.find(".browse_button");
var w = $btn.outerWidth();
var h = $btn.outerHeight();
var position = $btn.position();
var $hiddenInputDiv = $currPanel.find(".moxie-shim");
$hiddenInputDiv.height(h);
$hiddenInputDiv.width(w);
$hiddenInputDiv.css(
{
top: $btn.css("margin-top"),
left: position.left
});
I am interested in opening a webPanel on the right side of the Firefox window. Based on an MDN article, I determined that this could be done by setting the browser element's direction style. However, I wish to clear out this setting after the webPanel is closed. Is there a way I can detect this? Thus far, the only way I can think of is to poll sidebarWindow.location.href (to detect if the sidebar is changed) and sidebarHidden (to detect if the sidebar is closed).
var browser = document.getElementById('browser');
browser.style.direction = "rtl";
var sidebarWindow = document.getElementById("sidebar").contentWindow;
var sidebarBox = document.getElementById('sidebar-box');
var sidebarHidden = sidebarBox.collapsed || sidebarBox.hidden;
sidebarWindow.addEventListener("unload", function (event) {
alert("1"); //This code fires when the web panel is opened
//but not when it is closed.
});
sidebarBox.addEventListener("unload", function (event) {
alert("2"); //This code does not fire.
});
sidebarWindow.addEventListener("close", function (event) {
alert("3"); //This code does not fire.
});
sidebarBox.addEventListener("close", function (event) {
alert("4"); //This code does not fire.
});
openWebPanel('Test', 'http://www.google.com');
IIRC there are essentially three ways a sidebar can be "closed":
The user closes it using the GUI (X-box) or keyboard shortcut. In this case, the web panel will not necessarily get unloaded, so there is no unload event.
Another document is loaded into the web panel. In this case you might get an unload.
The user opens another panel. There is not necessarily an unload.
Should you go forward with your implementation, you need to make sure your code handles all three correctly.
and 3. should be observable by the <broadcaster id="viewWebPanelsSidebar"> changing the checked attribute (see the implementation of toggleSidebar()), so you could have another element observing and acting on onbroadcast.
should listen for unload and act accordingly.
To get proper unload events, I think the following should do the trick:
sidebar.contentDocument.getElementById("web-panels-browser")).
addEventListener("unload", ...);
But my memory there is a bit wonky, so you might need to fiddle with that a bit. (The sizebar has a <xul:browser id="web-panels-browser"> which displays the actual content...)
After having said all that: I think it is a bad idea to mess with the sidebar like this.
The MDN wiki(!) has bad advice in this case.
The sidebar was not designed to be messed with like this.
There are other add-ons "competing" with yours when it comes to messing with the sidebar.
The sidebar code is, for the most part, pretty archaic and under-maintained. Getting things like your requirement to work correctly is pretty hard. There still might be other code (in add-ons) that could dismiss the sidebar that you and I didn't think of.
The sidebar might not be the best place to display your content in the first place (what that content would be you didn't say). If it's something like context-help, dictionary/definition lookup results, login forms, then it won't be a good fit.
Some users might not like that their always-on bookmarks/history sidebar gets replaced by yours. You could handle this by re-opening the previous one, but that will only complicate matters further.
You might be better off using some other way to display information - e.g. a new tab, a panel, a new sidebar like the social sidebar... E.g the social sidebar is not only on the right, it actually is a standalone sidebar not part of the "main" sidebar.
I want the page to scroll to the top if its on a certain page of my app.
It needs to do this after the page has been shown.
I'm using the code:
$('.current-page, #'+desiredPage).toggleClass('current-page')
if(desiredPage === 'page-search-results'){
$(window).scrollTop(scrollPosition)
}else{
$(window).scrollTop(0)
}
however, the page scrolls to the top a split second before the class is actually toggled (the class has the css in it to show the page). Why is this? and how to make sure it only happens after?
This is only noticeable on mobile.
as per the comments/ answer i tried using:
$('.current-page, #'+desiredPage).toggleClass('current-page').promise().done(function(){
if(desiredPage === 'page-search-results'){
$(window).scrollTop(scrollPosition)
}else{
$(window).scrollTop(0)
}
});
but it still happens?
If you add a return false; at the end of the function (i.e. after the if/else clauses) it might solve the problem?
I've been wrestling with a similar problem, and found the hint at the bottom of this article:
http://chris-spittles.co.uk/jquery-smooth-page-scrolling/
It says there,
Returning false simply prevents the browser carrying out its default behaviour
For me, and in the example given on the page that means that the anchor does not jump down to the page before the animation, although, since your not using anchors, but toggling classes, I'm not quite sure what the "default behaviour" is in this case.
Hope it helps.