Here in this jsfiddle`
FlexSheet
</p>
<wj-flex-sheet initialized="initialized(s)" item-formatter="itemFormatter">
<wj-sheet name="Country" items-source="ctx.data"></wj-sheet>
<wj-sheet name="Empty Sheet"></wj-sheet>
</wj-flex-sheet>
` there are two buttons. One placed in a freeze cell and the others is in normal cell. When you click on the freeze cell button it doesn't work in Firefox and IE. But the other buttons does work. I can't figure out any work around.
Setting CloneFrozenCells to false resolves this. Update Fiddle
$scope.initialized = function (s) {
...
s.cloneFrozenCells = false;
};
If you set the cloneFrozenCells property to false, scrolling frozem cells will cause flicker on all browsers except Chrome (which is really fast).
If you set it to null (the default), the grid will try to guess whether it should be set to true of false. I believe it was not doing this correctly for Safari on the Mac. This has now been fixed in the latest build (482)
PS:
This is valid for FlexGrid and FlexSheet
Related
The goal is to make the drop down arrow for a <select> list disappear by setting the appearance property using JavaScript.
It:
Works for Chrome
Does not work for Firefox
For Firefox, the drop down arrow can be made to disappear by setting the appearance property in the style section. Whiskey Tango Foxtrot :)
Thanks for any help you can give.
To see the problem,
Run the page in Chrome. The drop down arrow will not appear. Good,
the JavaScript line for Chrome lower down on this page does its job
Run the page in Firefox. The drop down DOES appear. Bad, the
comparable JavaScript line for Firefox lower down on this page
DOES NOT do its job
Uncomment the line on CSS and run the page in Firefox. The dropdown will disappear.
//The next line works correctly for Chrome, it makes the drop down arrow disappear
//document.getElementById("mySelect").style.webkitAppearance = "none";
//The next line does NOT work for Firefox, the drop down arrow STILL appears
document.getElementById("mySelect").style.mozAppearance = "none";
select {
/*-moz-appearance: none; */
}
<select id="mySelect">
<option>red</option>
<option>green</option>
</select>
So, for Firefox, why does setting the property in JavaSript not work?
I am using Dojo 1.7 with an IE9 browser. I am trying to dynamically generate multiple DataGrids and append them to content inside a div. I am using the autoHeight property of the grid.
This works out fine in Chrome or Firefox. However, the grids are not displayed on IE until I set the height to a fixed amount.
How can I make autoHeight work in IE? I suspect its something to do with how IE9 treats height semantics.
I've been dealing with this same issue until a few minutes ago: I am creating dynamic grids depending on how many items I have in a list and every grid is shown with autoHeight. The problem is nothing to do with Grids or its height.
I am not sure but IE interpret layers in a different way than other browsers, so you have to add them in a concrete way. Try to add the grid first to your DOM node (I mean a node that you also create dynamically over which you will append the grid), then add in last place this grid container to your HTML. It is working correctly for me.
I also faced the same issue. I tried to find an alternate.
I followed this way and its working.
Add following property to
dojox.grid.datagrid
onShow: function(){if(grid)grid.setStore(store);}
And call grid.onShow();
var grid= new dojox.grid.DataGrid({
store : store,
query : {
sno : "*"
},
autoHeight:true,
structure : columns,
selectionMode : "Multiple",
onShow: function(){if(grid)grid.setStore(store);}
});
// This will fire the onShow event on grid.
grid.onShow();
On IE, I had to ensure that I called startup on the dynamically added grid. e.g. if you add the grid in postCreate, try this:
startup: function() {
this.inherited(arguments);
if (this.grid) this.grid.startup();
}
The grid can be fussy. Even doing this, I still have height issues on IE (IE9) with autoHeight. If I set an updated store after the fact, the height goes to 0.
I was looking at how to change the cursor over an HTML5 canvas when dragging the mouse...
Came across this: Change cursor over HTML5 Canvas when dragging the mouse
seemed logical that an :active pseudo-selector would do the trick...
When I used it on my page, however, the cursor set by the rule in the :active pseudo-selector was ignored, instead showing the text selection cursor.
In firefox, this behavior is not present - it obeys the cursor property I set.
Here's an example to demonstrate the behavior.
Any idea how to fix this in chrome?
Working Fiddle
Add the following for Chrome to turn off text selection while dragging and dropping.
document.onselectstart = function(){ return false; }
This has been answered a few times,
chrome sets cursor to text while dragging, why?
Click and Drag Cursor in Chrome
Something strange afoot, here:
An instance of Datepicker is showing up in a weird place as a single bar in the upper left hand corner of this page.
I'm using both jQuery UI's Datepicker and Accordion on a page. In the CSS for the UI, the display:none for Datepicker seems to be overridden by the display:block for the Accordion, at least according to Firebug (see img below).
Then, once the Datepicker trigger is clicked in the 'catering/event room' tab (click one of the buttons to show div with Datepicker,) the display:none seems to then work.
Here's what the bad div looks like:
and here's the Firebug panel:
I had the same problem and while some of the above solutions work, the easiest fix of all is to add this to your css:
#ui-datepicker-div {display: none;}
This basically hides the realigned datepicker element when it cannot be binded to an existing invisible element. You hide it, but it will be initialized again when you click on an element that needs to display the datepicker. Upon re-initialization, the datepicker element with id #ui-datepicker-div will have the correct position.
In my case, I use the session "$(document).ready(function(){" of JQuery in my favor.
As I have a JavaScript file that is loaded in all pages of my system, I just added the following line on it.
$('#ui-datepicker-div').css('display', 'none');
For me, it appears a clear and elegant solution because I did not have to change its library.
Best of all, it is working fine on all browsers. :)
The problem could be that you're binding the datepicker to something that is not visible, that would explain the odd positioning (trying to offset from something that doesn't exist will degenerate to offsetting from (0,0)). The datepicker <div> should have at least a table inside it so maybe the datepicker is getting confused and throwing an exception before it finishes initializing itself. When you click on one of the bound inputs, it is probably initializing itself again (or at least properly finishing the initialization) and everything works fine after that.
Try binding the datepicker when the date input becomes visible:
Remove the $(".date_picker").datepicker({ disabled: false });
Add an id="cater" to <input type="text" name="cater"/>
Call $('#cater').datepicker(); when the "reserve event room" button is pressed.
If that works then you'd have to add similar hacks for other datepickers. If it doesn't work then I'm probably wrong. If my guess turns out to be right then you might want to report a bug to the jQuery-UI people.
BTW, in Safari I can only see the first two tabs, I had to switch to Firefox to see the "catering" tab. Oddly enough it works just fine in Chrome. This is probably unrelated but I thought I'd let you know anyway.
The problem is down to the element the datepicker is being binded to not yet being available.
The solution I found was to initalize the datepicker when the actual element has been clicked and then showing it straight after initalization. This ensures the element is available before the datepicker has been binded to it and initalized.
$(function() {
$(".date_input").click(function() {
$(this).datepicker();
$(this).datepicker("show");
});
});
....
<input type="text" class='date_input' />
I had a similar problem in Chrome and I solved it editing jquery-ui1.7.2.custom.css
from:
.ui-helper-hidden-accessible { position: absolute; left: -99999999px; }
to:
.ui-helper-hidden-accessible { position: absolute; left: -9999999px; }
There's probably too many nines for Chrome.
Try moving the last block to the bottom of the page (right before you close the body tag). You can read more about why you want to do this here:
http://webdevel.blogspot.com/2008/09/place-javascript-code-at-bottom-of-page.html
BTW: Cool idea for a menu. I like it.
Sometimes it has to do with the z-index of another item on the page being higher. Setting the z-index to a very high number solved my issue.
#ui-datepicker-div {z-index:11111;}
I'm having a problem with FIREFOX. I have an invisible list control over a drop-down control (html 'select'). Don't mind why, but I will say that the over-layer is a pop-up that appears as part of another custom control.
Even though it's hidden, it's preventing me from clicking on the underlying drop-down control, making the underlying control seem disabled. It's not disabled though, because I can tab over to it. I just can't click on it. I know it's the overlay causing the problem, because I moved the underlying control off to the side and it works again.
Is this a bug in Firefox? This isn't like setting a translucency value; it's disabling rendering of the control altogether, so I don't think such an invisible control should be intercepting mouse events.
This behavior does not occur in Internet Explorer.
Perhaps there is some other CSS property I can set in JavaScript to toggle its mouse event capturing ability along with its visibility.
dd = document.getElementById('lstStudents');
if (dd.style.visibility == 'hidden') dd.style.visibility = 'visible'; else dd.style.visibility = 'hidden';
Update: I just read a description for the CSS visibility value "hidden" that read "The element is invisible (but still takes up space)". So I guess I'll have to set it's height to zero along with setting it's visibility to solve this problem.
change your over-layer control's z-index to, say, -1. style="z-index: -1;" This will place it underneath everything, allowing direct access to drop-down. You might have to dynamically change the z-index to bring over-layer back on top when visible.
More info
How are you hiding the element? If I remember it right, "visibility: hidden" is supposed to (rightly) work the way you describe, while "display: none" will banish rendering altogether.
If that's not the cause, can you confirm using Web Developer Toolbar that it is indeed the invisible control that is causing the problem and not another that has opacity set to 0 or something?
The way I've done popup boxes before in Firefox was with CSS properties.
z-index: 500;
display: block;
to show an element, and
z-index: -10;
display: none;
to hide it.
Now. My values for z-index are extreme, but that's just what I chose. This works for me, but my app targeted Firefox specifically; aaaaand I'm using the display property, which you stated you want to avoid.
If you're concerned about using display:block or display:hidden, I think maybe you could try to play with positioning, or sizing the element.
Either make the popup element absolutely positioned and move it offscreen when invisible, or maybe try to make it 0px width and 0px height when invisible. That's two things I would potentially explore if I still had problems. I'm not sure if I would recommend these as best solutions though.
Really consider how many instances of your popup elements will have different display values, I found in my case to be using only two types, 'none', and 'block'. Maybe manipulating the display property will be enough for you.
Hope this helps.