I don't know what exactly to change about the following code to make it work in Firefox 15:
eventDrop: function (event, dayDelta) {
updateCalendarEvent(event.id, dayDelta);
//Firefox 15 fires eventClick for no good reason???
},
eventClick: function (event) {
alert('event click');
if (event.url) {
alert(event.url);
vUrl = '../Activities/' + event.url;
openActivityAddEditDialog(vUrl, 'Edit Activity');
return false;
}
},
I have done a fair bit of research and this is definitely a BUG. Code works fine in Chrome, Safari, Firefox 14 & even IE - but not Firefox 15. It's been almost 2 months and no fix is in sight.
Someone posted this about a work-around hack here:
http://code.google.com/p/fullcalendar/issues/detail?id=1523
Another similar unanswered Full Calendar Firefox SO question:
Full Calendar event hyperlinks automatically fire in Firefox
You will also have some event data like this:
events: [
{id: '76',title: 'Hot Shave',data: 'Some data',start: new Date(2012,9, 17, 13 , 55),end: new Date(2012,9,17, 13 , 115),allDay: false, url: '<someurl>'}
],
Change the event where it says "url:" to "workingurl:" and update your eventclick code to be:
eventClick: function (event) {
alert('event click');
if (event.workingurl) {
alert(event.workingurl);
vUrl = '../Activities/' + event.workingurl;
openActivityAddEditDialog(vUrl, 'Edit Activity');
return false;
}
},
That should stop FF firing off the click based on the url: property which then no longer exists.
When you include the 'url' attribute in your event JSON FullCalendar will render the event as an an <a> link rather than a <div>.
It looks like Firefox is treating the drag and drop of the <a> as a click and following the URL. This results in the AJAX request getting interrupted and returning status=0 as documented here:
https://developer.mozilla.org/en-US/docs/DOM/XMLHttpRequest/Using_XMLHttpRequest?redirectlocale=en-US&redirectslug=Using_XMLHttpRequest#XMLHttpRequests_being_stopped
In my case (Firefox 18) this is resulting in a "You are offline! Please check your network" warning message.
Renaming the 'url' attribute to 'targetUrl' causes the event to be rendered as a <div> solving the problem. You then need to modify your eventClick handler to use the new attribute accordingly.
Even after putting breakpoints for all functions in fullcalendar.js - the error still happens and no full calendar functions are getting fired after eventDrop completes - but the re-direct still happens.
ONLY IN FIREFOX 15!
Also changed to earlier versions of jquery - but no difference.
I have seen some recent posts about Firefox 15 and drop event bugs, but nothing applies to this specifically.
Is anyone out there having this problem?
If not - is there a way to only disable drag & drop for Firefox users?
Related
Hi I have a wired issue which I really dont know how can I explain to you guys. But I will try my best. Here is a jquery script I'm using on my site for calling different jquery functions or plugins like typed.js, flexislider etc etc.
(function ($) {
//Typed JS
$(".element").typed({
strings: ["Saumya Majumder.", "a geek.", "an Engineer.", "a Code Lover.", "a Google fan.", "an Apple fan.", "an Android fan.", "a WordPress fan.", "an Inventor.", "a Coffee lover.", "a Tea lover."],
typeSpeed: 100,
backDelay: 3000,
loop: true
});
// Flixislider
$('.flexslider').flexslider();
/* TOOLTIPS */
$('.tooltip').each(function(index, element) {
$(this).tooltipster({
position: $(this).attr('data-tooltip-pos'),
fixedWidth : 300,
offsetX : 8,
animation : "grow",
delay : 50
});
});
$('.bar').each(function() {
var bar = $(this);
bar.find('.progress').css('width', bar.attr('data-percent') + '%' );
});
})(jQuery);
Now 1st I must tell that this is working fine with chrome and opera but creating issue on firefox.
Here is the issue:
In firefox when a user is visiting my page where I have the typed element to triger, but no flixislider to trigger and again a bar element to trigger. Whats happening is firefox 1st triggers the typed element as there is a call for that on the same page, and then it see that the page does not have any flexslider call, so it thwos and error and dont even read the below calls whether or not is there any more thing that might have used on that page.
But in chrome and opera, it just ignores the calls which are not present in that page. Sleek and exactly the thing I need.
Now suppose in a page where I dont have the typed element, it thwos error for the very 1st call and dont even check the rest. So none of my plugin calls will work.
What I'm looking for
As this is a firefox specific issue can anyone tell me how can I update my script code so that firefox just ignores the calls that are not ment for that page and execute the calls which are present on that page, like chrome, firefox.
You could check if there is any .flexslider before call the function :
if ($(".flexslider")[0]){
$('.flexslider').flexslider();
}
I have the following situation on a web application.
A dialog is built and opened on the fly when clicking on a link:
var dialogInitiator = $("<div id='dialog-initiator' style='background-color: "+bgcolor+";'>Loading...</div>");
dialogInitiator.appendTo(parentFrame);
dialogInitiator.dialog({
modal:true,
autoOpen: false
}).on('keydown', function(evt) {
if (evt.keyCode === $.ui.keyCode.ESCAPE) {
dialogInitiator.dialog('close');
}
evt.stopPropagation();
});
dialogInitiator.dialog('open');
Right after that, I load a new html page into the dialog, with an < object >, like this:
var objectFrame = $('<object style="border: 0;width:'+(dlwidth-30)+'px;min-height:'+(dlheight-46)+'px;" type="text/html" style="overflow:auto;" data="'+url+'"></object>');
dialogInitiator.html(objectFrame);
Now, the "url" variable contains a link to this new html document. When that page is ready, it will focus on an input field. This prevents the ESCAPE key from closing the dialog. So, I am trying to manually trigger the .dialog('close') event on escape keypress.
I do the following, from within the loaded document:
$('#dialog-initiator', window.parent.document).dialog('close');
It get the following error:
"Error: cannot call methods on dialog prior to initialization; attempted to call method 'close'"
Strange thing is, when i call:
console.log( $('#dialog-initiator', window.parent.document).html() );
it shows me the html from the dialog. So it actually IS initiated.
Well, I have tried to fix this error with the help of Google, but without success. I guess my situation is quite specific.
Note: we are forced to use the technique with loading this whole webpage into the dialog due to older functionality we used in modalDialogs. Since they are depricated in the latest Google Chrome, we've built a temporary solution with jQuery dialog.
I hope someone can help me out. I appreciate it!
You can try a global method created after the modal is created
dialogInitiator.dialog({
modal: true,
autoOpen: false,
create: funtion(e,ui) {
window.closeMyDialog = function() {
$('#dialog-initiator').dialog('close');
};
}
})...
Then call it by doing window.parent.closeMyDialog();.
Why not use JQuery UI? It's easier than making your own.
http://jqueryui.com/dialog/#default
The Dojo mobile DatePicker - dojox.mobile.ValuePickerDatePicker - is behaving incorrectly:
Clicking on the plus(+) and minus(-) buttons for the year updates the day value and the otherway around.
This only appears on the device and never in a browser during development. Have reproduced on multiple Android devices.
This is also somewhat intermittent in that the steps to reproduce are not exactly the same every time. However once it starts to go wrong it continues to be wrong...
To reproduce: in the Date Picker widget, repeatedly and randomly click on the plus(+) and minus(-) buttons and on the editable fields. Eventually the fields will start to update incorrectly. (I would like it to be more predictable)
Have never reproduced the error on my PC/MAC.
I have a suspicion that the predictive text on the device is interfering, but I have no proof of that.
You can reproduce the error with the widget/Date Picker on its own. Tested with Dojo version 1.9.4 and 1.10.1. The Date Picker is created declaratively:
<div id="dateSelectorDatePicker" data-dojo-type="dojox.mobile.ValuePickerDatePicker" data-dojo-props="slotOrder:[2,1,0]"></div>
Try this example in your browser on a Android device http://jsfiddle.net/sport_johan/q943mbrs/1/
We fixed the problem by creating a new versions of the dojox.mobile.ValuePickerSlot
class and the dojox.mobile.ValuePickerDatePicker class.
In the MyValuePickerSlot which is a copy of ValuePickerSlot we are using click events instead touch events.
So first copy ValuePickerSlot.js and then inside MyValuePickerSlot.js you remove the following handlers:
// this.connect(this.plusBtnNode, touch.press, "_onTouchStart"),
// this.connect(this.minusBtnNode, touch.press, "_onTouchStart"),
and instead add
this.connect(this.plusBtnNode, "onclick", "_onClick"),
this.connect(this.minusBtnNode, "onclick", "_onClick"),
You can also remove the functions _onTouchStart, _onTouchMove and _onTouchEnd since you wont be using them anymore.
You now have to create a new class MyValuePickerDatePicker which inherits all functionality from the original class but you override the constructor that creates the slot classes which now are the new MyValuePickerSlot.
define(["dojo/_base/declare",
"dojo/_base/lang",
"dojox/mobile/ValuePickerDatePicker",
"myApp/dojox-fix/MyValuePickerSlot"],
function (declare, lang, ValuePickerDatePicker, MyValuePickerSlot) {
return declare("myApp.dojox-fix.MyValuePickerDatePicker",[ValuePickerDatePicker], {
// Override of the ValuePickerDatePicker to fix a touch event bug
// on Android device
constructor: function (args) {
this.slotClasses = [
MyValuePickerSlot,
MyValuePickerSlot,
MyValuePickerSlot
];
lang.mixin(this, args);
}
});
});
You can now use the MyValuePickerDatePicker in your code instead of the broken ValuePickerDatePicker.
<div id="dateSelectorDatePicker" data-dojo-type="myApp.dojox-fix.MyValuePickerDatePicker" data-dojo-props="slotOrder:[2,1,0]"></div>
A side effect is that you can't press and hold the +/- buttons if you want to scroll far; you will have to repeatedly press the button(s), but you can still type in a value, so it is not big a problem.
Edit: It's not only a ExtJs-issue; it doesn't work on pure SVGs with pure Javascript either.
I have an Ext.draw.Sprite that is defined like
Ext.create('Ext.draw.Sprite', {
type : 'path',
stroke : 'lightgrey',
'stroke-width' : 8,
path : path,
listeners : {
mouseover : Handler.clickZoneMouseOver,
mouseout : Handler.clickZoneMouseOut,
click : Handler.clickZoneClick,
mousedown : Handler.clickZoneMouseDown,
mouseup : Handler.clickZoneMouseUp
}
});
The Handler simply says
console.log('mouseover')
On Google Chrome it works perfect and without any problems. Unfortunately, on Firefox the mouseover- and the mouseout-Events are only fired "sometimes". So when I perform 10 mouseovers and mouseouts, the event is fired like once or twice.
I wanted to create a jsfiddle that shows the problem, but there it works without any problems... http://jsfiddle.net/P6Ny3/
So it may be a Problem with the ExtJS-Listener classes...
Does someboy know, what may be the problem in this case?
Thank you for your help!
EDIT:
I managed to create a jsfiddle, that shows exactly my problem!
http://jsfiddle.net/8r327/2/
There is - also in pure javascript - a strange behaviour on firing the events!
I think you are hitting the following FF bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=676001
It's been reported 2 years ago, has multiple duplicates, but as of now have not been fixed yet. :(
I'm using ExtJS 3.2.1 and I need a component almost identical to the bundled HtmlEditor, with one exception: it must start editing the HTML source code directly. The reason I don't use a normal TextArea is that the user should be able to preview the result of his actions before submitting.
I've tried calling toggleSourceEdit(), as per ExtJS documentation, with no success. Debugging, I see that the editor object has the sourceEditMode property set to true, and the Source Edit button seems as if it was "pressed", but clicking on it does not render the typed HTML, and clicking it again goes to the Source Mode.
I've tried calling toggleSourceEdit() after the container show() method, on the container afterLayout listener and on the editor afterRender listener. I've tried also calling it on another button that I added to the container. The result is the same on every try.
The only other option I see is updating ExtJS to 3.3.0, but I haven't seem anything related on the changelogs. Either way, it's going to be my next step. EDIT: The app had another problems when updating, we'll make a bigger effort to update later. As of right now, we are using the HtmlEditor in its original setting.
Thanks!
ran into the same problem (using 3.3.0 by the way)
stumbled upon a fix by dumb luck. i have no idea why this works, but second time is the charm. call it twice in a row to achieve the desired effect..
HTMLEditor.toggleSourceEdit(true);
HTMLEditor.toggleSourceEdit(true);
hope that helps!
Rather calling toggleSourceEdit(), try to setup the configuration while you create HtmlEditor Object
Using toggleSourceEdit() caused some problems for me. One was that this seemed to put the editor somewhere in limbo between source edit and WYSIWYG mode unless I used a timeout of 250ms or so. It also puts the focus in that editor, and I don't want to start the form's focus in the editor, especially since it's below the fold and the browser scrolls to the focused html editor when it opens.
The only thing that worked for me was to extend Ext.form.HtmlEditor and then overwrite toggleSourceEdit, removing the focus command. Then adding a listener for toggling to the source editor when the component is initialized. This is for Ext 4.1 and up. For older versions, replace me.updateLayout() with me.doComponentLayout().
var Namespace = {
SourceEditor: Ext.define('Namespace.SourceEditor', {
extend: 'Ext.form.HtmlEditor',
alias: 'widget.sourceeditor',
initComponent: function() {
this.callParent(arguments);
},
toggleSourceEdit: function (sourceEditMode) {
var me = this,
iframe = me.iframeEl,
textarea = me.textareaEl,
hiddenCls = Ext.baseCSSPrefix + 'hidden',
btn = me.getToolbar().getComponent('sourceedit');
if (!Ext.isBoolean(sourceEditMode)) {
sourceEditMode = !me.sourceEditMode;
}
me.sourceEditMode = sourceEditMode;
if (btn.pressed !== sourceEditMode) {
btn.toggle(sourceEditMode);
}
if (sourceEditMode) {
me.disableItems(true);
me.syncValue();
iframe.addCls(hiddenCls);
textarea.removeCls(hiddenCls);
textarea.dom.removeAttribute('tabindex');
//textarea.focus();
me.inputEl = textarea;
} else {
if (me.initialized) {
me.disableItems(me.readOnly);
}
me.pushValue();
iframe.removeCls(hiddenCls);
textarea.addCls(hiddenCls);
textarea.dom.setAttribute('tabindex', -1);
me.deferFocus();
me.inputEl = iframe;
}
me.fireEvent('editmodechange', me, sourceEditMode);
me.updateLayout();
}
})
}
Then to use it:
Ext.create('Namespace.SourceEditor', {
/*regular options*/
listeners: {
initialize: function(thisEditor) {
thisEditor.toggleSourceEdit();
}
}
});
htmlEditor.toggleSourceEdit(true);
one time should be enough if you do this listening to the afterrender event of the editor.