PDA

View Full Version : [OPEN] Submenus disappear in Chrome 43 beta



lenau0
15 May 2015, 1:45 AM
If I try to select a submenu with the mouse in ExtJS 4.X it disappears as soon as I leave the parent and try to hover over the actual submenu.

It can be easily reproduced, just go to: http://docs.sencha.com/extjs/4.2.3 and try to select another version of the documentation with the menu from the drop down "Sencha Docs" The menu does not allow you to switch because the submenus disappear before you can click.

Any ideas what's going on and how to fix that? Our product is now broken. Fortunately only <5% of our customers are on beta and we can ask them to switch to stable. But we need to find a solution before Chrome 43 gets promoted to stable.

I've tested it in this environment:
Mac OS X 10.10.1
Chrome Version 43.0.2357.65 beta (64-bit)

Gary Schlosberg
15 May 2015, 2:52 PM
This doesn't seem to be a bug with Ext JS, since it occurs without using the framework at all. We also generally don't file bugs against beta versions of browsers. I personally can't imagine Google will release such a bug.

Update: I stand corrected. :-)

lenau0
15 May 2015, 10:40 PM
Thanks! How do you know the error is not ExtJS specific? Can you show me your test-case? It would mean something is broken with Chrome's Javascript implementation or whatever.

If I had a test case I could simply file a bug with the Chrome team. They are usually very responsive if it's something fundamental like that.

But at the moment I just don't know what's broken here and I can't file a bug which I can only reproduce for a specific framework.

lenau0
15 May 2015, 10:59 PM
The problem is from what I can see it's even specific to ExtJS 4.X and does not occur in 5.X, as can be easily tested in the docs:

http://docs.sencha.com/extjs/4.1.3/#!/example/menu/menus.html
http://dev.sencha.com/ext/5.1.0/examples/menu/menus.html

Usually we don't care if something is broken in Canary or Dev channels, but once it's in Beta for several weeks we get nervous because they can switch the button at any time. What has been put away as 'beta issues' is suddenly 'stable' and pushed to all users. We've been there, so we try to address this in time.

Any hint what the problem could be would help to either get it fixed in Chrome or to fix it ourselves in ExtJS.

Nom4d3
19 May 2015, 9:37 AM
I was getting this problem on Opera 31 (Uses chromium 43). But since it's not the final version I ignored. But now, my Chrome just updated to 43 stable channel and this bug is happening too. Like lenau0 said. ExtJS 5 is free of this bug.Is there any override for this? My customers started to call me about this bug this morning. They are using the keyboard to access submenus :(

festr
20 May 2015, 1:35 AM
I was getting this problem on Opera 31 (Uses chromium 43). But since it's not the final version I ignored. But now, my Chrome just updated to 43 stable channel and this bug is happening too. Like lenau0 said. ExtJS 5 is free of this bug.Is there any override for this? My customers started to call me about this bug this morning. They are using the keyboard to access submenus :(

hello did you find solution for this? I have the same problem.

izopi4a
20 May 2015, 1:50 AM
Working on solution aswell.
Works in chrome 45 btw... but relase date is in 2 months i guess....

skwee
20 May 2015, 2:06 AM
fine in chrome 42, broken in chrome 43 (released on May 19)
testet on Windows 7 and Mac OS X
i filed a support ticket on the subject

festr
20 May 2015, 2:44 AM
we have fix this problem with this override



// fix hide submenu (in chrome 43)
Ext.override(Ext.menu.Menu, {
onMouseLeave: function(e) {
var me = this;


// BEGIN FIX
var visibleSubmenu = false;
me.items.each(function(item) {
if(item.menu && item.menu.isVisible()) {
visibleSubmenu = true;
}
})
if(visibleSubmenu) {
//console.log('apply fix hide submenu');
return;
}
// END FIX


me.deactivateActiveItem();


if (me.disabled) {
return;
}


me.fireEvent('mouseleave', me, e);
}
});

Nom4d3
20 May 2015, 3:55 AM
Thanks festr!Your override works like a charm!Regards!

jkerr
20 May 2015, 4:00 AM
By the way, it IS a problem in 5 as well - Hit the live preview in the example in the API docs, then mouse over all options - after mousing from the top 3 to the bottom 3, the top 3 disappear...http://docs.sencha.com/extjs/5.1/5.1.0-apidocs/#!/api/Ext.menu.Menu

E (http://docs.sencha.com/extjs/5.1/5.1.0-apidocs/#!/api/Ext.menu.Menu)dit: Ok, may be a separate thing, not sub-menu related, but certainly strange? My friend says the API docs live code uses extjs 4.1 so may not be an issue...

bmacdon1
20 May 2015, 5:15 AM
@Gary

It is not considered beta anymore. You can see that if you run an update. Also, there is a much broader impact.

Gary Schlosberg (https://www.sencha.com/forum/member.php?556932-Gary-Schlosberg)

This doesn't seem to be a bug with Ext JS, since it occurs without using the framework at all. We also generally don't file bugs against beta versions of browsers. I personally can't imagine Google will release such a bug.

Gary Schlosberg
20 May 2015, 6:18 AM
Apologies for my being wrong about this. We've filed EXTJS-17866 to track this issue.

bmacdon1
20 May 2015, 6:23 AM
Gary,
Thank you for responding and filing a bug. Just wanted to make sure it wasn't overlooked because of the beta version of the original post. However, I would imagine google will probably patch soon. It has caused us other problems as well, but I think for now we are going to try and weather the storm.

Thanks again,

Bryan

mharris45
20 May 2015, 8:50 AM
A similar issue seems to be with charts rendered to a card/tabpanel. Sometimes they will display correctly in Chrome 43, other times you have to either resize panel or change tabs. Is not happening in < Chrome 43 or any other browsers.

aokegbile
20 May 2015, 1:18 PM
Thanks for the Override.. Works like a charm.

lenau0
20 May 2015, 10:40 PM
Thanks for the override. I really appreciate it.

I pushed it and could avoid a disaster, as only a relatively small fraction of our customers seem to have updated yet to 43.

In the end it does not matter if it's a bug in Chrome or in ExtJS, for the customer it's always your product that is broken. So again, many thanks for that.

theonlydavewilliams
21 May 2015, 2:27 AM
Thank you festr, you rockstar; your patch did the trick. Fortunately only a few of our users alerted us to it as well and you saved us just in time.

Cheers

festr
21 May 2015, 2:42 AM
all credits goes to my college Radek :) But EXTJS-17866 - is this something we can track? Once sencha fixes it we would like to remove our workaround and go with stock version.

Gary Schlosberg
21 May 2015, 11:01 AM
This forum thread is linked to the bug ticket, so the message at the top of the page will change once the bug has been fixed.

jvisser
22 May 2015, 12:49 AM
Whoops!

In the first line add "var" otherwise visibleSubmenu will be leaking into the global scope!

@festr could you fix your code by editing your post?

siq
22 May 2015, 12:55 AM
A better fix:



Ext.override(Ext.menu.Menu,{
onMouseOver: function(e) {
var me = this,
fromEl = e.getRelatedTarget(),
mouseEnter = !me.el.contains(fromEl),
item = me.getItemFromEvent(e),
parentMenu = me.parentMenu,
ownerCmp = me.ownerCmp;

if (mouseEnter && parentMenu) {
//original
//parentMenu.setActiveItem(ownerCmp);
//ownerCmp.cancelDeferHide();
//parentMenu.mouseMonitor.mouseenter();
//end original

//fix
if(ownerCmp){
parentMenu.setActiveItem(ownerCmp);
ownerCmp.cancelDeferHide();
}
setTimeout(parentMenu.mouseMonitor.mouseenter,5);
//end fix
}

if (me.disabled) {
return;
}

// Do not activate the item if the mouseover was within the item, and it's already active
if (item && !item.activated) {
me.setActiveItem(item);
if (item.activated && item.expandMenu) {
item.expandMenu();
}
}
if (mouseEnter) {
me.fireEvent('mouseenter', me, e);
}
me.fireEvent('mouseover', me, item, e);
}
});

jvisser
22 May 2015, 2:01 AM
A better fix:


Why do you think it's better? I'd like to know because then I will use yours instead of the previous fix.

festr
22 May 2015, 2:01 AM
Whoops!

In the first line add "var" otherwise visibleSubmenu will be leaking into the global scope!

@festr could you fix your code by editing your post?

done

theonlydavewilliams
22 May 2015, 2:11 AM
no harm patching both?

enw
22 May 2015, 4:34 AM
Ext.override (Ext.menu.Menu,
{
// Workaround event emission order change in Chrome 43; without this submenus are
// not navigable with mouse, because they get hidden.
onBoxReady: function ()
{
this.callParent ();

var monitor = this.mouseMonitor;
var mouseenter = Ext.Function.bind (monitor.mouseenter, monitor);
monitor.mouseenter = function () { setTimeout (mouseenter, 0); }
}
});

siq
22 May 2015, 5:08 AM
When you are moving the mouse from one box to another, chrome43 will fire the "mouseover" event on the second box before the "mouseleave" on the first one. On other browser the events sequence runs as expected (first mouseleave and then mouseover). Try http://jsfiddle.net/eo8z1g7u/ with ff /chrome 42 and chrome 43, the events order will be different.

The temporary solution is to slightly defer any function called by mouseover event.


Here's an override that should potentially solve any mouseover-related issues caused by chrome 43's wierd behaviour, and not only those seen on menus.



Ext.apply(Ext.EventManager,{
normalizeEvent: function(eventName, fn) {

//start fix
var EventManager = Ext.EventManager,
supports = Ext.supports;
if(Ext.chromeVersion >=43 && eventName == 'mouseover'){
var origFn = fn;
fn = function(){
var me = this,
args = arguments;
setTimeout(
function(){
origFn.apply(me || Ext.global, args);
},
0);
};
}
//end fix

if (EventManager.mouseEnterLeaveRe.test(eventName) && !supports.MouseEnterLeave) {
if (fn) {
fn = Ext.Function.createInterceptor(fn, EventManager.contains);
}
eventName = eventName == 'mouseenter' ? 'mouseover' : 'mouseout';
} else if (eventName == 'mousewheel' && !supports.MouseWheel && !Ext.isOpera) {
eventName = 'DOMMouseScroll';
}
return {
eventName: eventName,
fn: fn
};
}
});

theonlydavewilliams
22 May 2015, 5:26 AM
thanks for the cool explanation

mcouillard
22 May 2015, 7:09 AM
Thank you, siq, your solution on post 27 is nicely generic and seems to work well.

westy
22 May 2015, 7:11 AM
Has this event emission order issue been reported to the Chromium team like the form field one in Ext 5?

It's more serious quite frankly...

tglover
22 May 2015, 7:32 AM
Where should I put this code fix? Does it just go in the file that has the grid in it?

richardconrad
22 May 2015, 9:33 AM
Anyone know the issue on Chrome's end? Is it this one?

Ordering issue with mouseout vs mouseenter:
https://code.google.com/p/chromium/issues/detail?id=475193

skirtle
22 May 2015, 10:51 AM
My thanks to those who've already worked on fixes for this problem, it saved me a lot of time. I've attempted to patch this using relatedTarget instead of a timer:


Ext.define('MyApp.menu.Menu', {
override: 'Ext.menu.Menu',

onMouseLeave: function(ev) {
var activeItem = this.activeItem,
menu = activeItem && activeItem.menu,
menuEl = menu && menu.getEl();

if (Ext.isChrome && menuEl && menuEl.contains(ev.getRelatedTarget())) {
return;
}

this.callParent([ev]);
}
});

I assume ExtJS 5 is immune because it simulates mouseenter/mouseleave rather than relying on the browser events.

KostasP
25 May 2015, 3:23 PM
Can someone explain where should these FIXES / OVERRIDES / ETX be pasted to? Main .js file? Controller file?

westy
25 May 2015, 11:50 PM
Can someone explain where should these FIXES / OVERRIDES / ETX be pasted to? Main .js file? Controller file?

Lots of info in the documentation on overrides, but in a nutshell you put them in your top-level overrides folder, in a path that aligns with the overridden class, so the above Ext.menu.Menu override will go in root\overrides\menu\Menu.js - then do a "sencha app refresh" or "sencha app build" so it gets picked up.

Sass follows a similar structure, so a text field sass override will go in sass\src\Ext\form\field\Text.scss (although that's assuming your root namespace for sass is the empty string, otherwise it'll have to go in your theme or something).
Sass root is in your package/app.json iirc.

Hope that helps,
Westy

westy
25 May 2015, 11:55 PM
Anyone know the issue on Chrome's end? Is it this one?

Ordering issue with mouseout vs mouseenter:
https://code.google.com/p/chromium/issues/detail?id=475193

From the sounds of that thread they don't sound very clear as to what ordering they want, although there is mention that it's "more correct" now.
I'm guessing we'll need a patch from Sencha for that one, rather than waiting for a Chrome update...

26 May 2015, 1:03 AM
Thanks for sharing this guys. I tend to use @siq (post #27) 's patch, since it targets the root-cause of the issue.

moogjet
26 May 2015, 1:39 AM
This also affects Ext 5.x. Does the bug raised here also cover that or do we need another thread in the Ext 5 forum?

westy
26 May 2015, 1:56 AM
This also affects Ext 5.x. Does the bug raised here also cover that or do we need another thread in the Ext 5 forum?

Does it?

moogjet
26 May 2015, 1:56 AM
Ext.override (Ext.menu.Menu,
{
// Workaround event emission order change in Chrome 43; without this submenus are
// not navigable with mouse, because they get hidden.
onBoxReady: function ()
{
this.callParent ();

var monitor = this.mouseMonitor;
var mouseenter = Ext.Function.bind (monitor.mouseenter, monitor);
monitor.mouseenter = function () { setTimeout (mouseenter, 0); }
}
});
I'm using this one on Ext 5.0.1 and it seems to work. Anyone come up with any disadvantages to it? It seems the simplest.

moogjet
26 May 2015, 1:58 AM
Does it?Yes

westy
26 May 2015, 2:04 AM
Yes

Ah, 5.0.

moogjet
26 May 2015, 2:09 AM
Ah, 5.0.Ah, I've just checked. It doesn't happen in Ext 5.1.1 so I guess a new thread isn't too helpful as it'll just be marked as fixed.

Stokes
26 May 2015, 4:52 PM
I liked siq's solution in #27, but changed it to not include any copy-and-pasted core code. Including below in case it helps anyone. Also, others in this thread asked about how to include overrides in their code. This version follows a style we use that works well. See code docs below for usage.




/**
* Bug fix overrides for the Ext.EventManager class.
*
* Simply include this class in the 'requires' section of your top-level entry point, and/or any specific class that
* requires this fix.
*/
Ext.define('YourCompanyNameHere.overrides.ext.EventManager', {
requires: [
'Ext.EventManager'
]
}, function () {

// EventManager is not a normally define()d class, so we can't use Ext.override(). Instead, we 'backup' its
// original normalizeEvent() function, and replace it with our wrapper function.
var origNormalizeEvent = Ext.EventManager.normalizeEvent;
Ext.apply(Ext.EventManager, {
normalizeEvent: function(eventName, fn) {
// If this is Chrome 43, then it suffers from the bug logged as
// https://code.google.com/p/chromium/issues/detail?id=475193, and discussed at length in
// https://www.sencha.com/forum/showthread.php?301116-Submenus-disappear-in-Chrome-43-beta.
// Here we workaround by putting a delay in processing any mouseover events so that other events
// (namely mouseleave) can be processed first. Then we call the original normalizeEvent method.
if (Ext.chromeVersion >= 43 && eventName == 'mouseover') {
var origFn = fn;
fn = function () {
var me = this, args = arguments;
setTimeout(
function () {
origFn.apply(me || Ext.global, args);
},
0);
};
}
return origNormalizeEvent.call(this, eventName, fn);
}
});
});

VirtualGreg
27 May 2015, 10:55 AM
I'm actually seeing something like this in Chrome and Firefox, when running Siesta tests. I have a button with a menu and sub-menus, and when I execute a click action on the button and then the first-level menu, the mouse moves diagonally to the sub-menu item, which causes the menu to disappear.

I'm wondering what approach was used to find the fix for this bug, as I might be able to use that approach to find a fix for the issue I am currently facing.

Thanks in advance.

Gary Schlosberg
27 May 2015, 2:46 PM
The first override on this announcement should help with the submenu issue:
https://www.sencha.com/forum/announcement.php?f=80&a=58

VirtualGreg
27 May 2015, 2:59 PM
Hmmm... Maybe somethings going on in our app, because this did not work for me:


Ext.define('Override.menu.Menu', {
override: 'Ext.menu.Menu',


compatibility : '4',


onMouseLeave: function(e) {
var me = this;


// If the mouseleave was into the active submenu, do not dismiss
if (me.activeChild) {
if (e.within(me.activeChild.el, true)) {
return;
}
}
me.deactivateActiveItem();
if (me.disabled) {
return;
}
me.fireEvent('mouseleave', me, e);
}
});

carsten.ennulat
28 May 2015, 8:17 AM
Thanks for your overwrite. Works well for me.

m.zeug
29 May 2015, 5:55 AM
Apparently a Chrome update is on the way: https://code.google.com/p/chromium/issues/detail?id=492415

jhoweaa
29 May 2015, 6:12 AM
Thanks for the fix. I do have a question about it, however. I tried the fix in my development environment and it worked perfectly. However after building and deploying the application to a test box, the 'built' environment still has the problem. I looked at the all-classes.js to verify that the override was in the code and it was. Is there some other step that I'm missing to get this to work in a built environment?

For clarification, in my 'app' directory I created a folder called 'overrides' and a subfolder called 'ext'. In the app/overrides/ext I created a file called EventManager.js and I included your patch. I renamed the patch to match my application name (i.e. Ext.define('MyApp.overrides.ext.EventManager', ...). In my app.js file I added this file to the Ext.require array. Have I missed any steps needed to get this to work in a build?

Thanks.

Jim

Shreesh
1 Jun 2015, 4:00 AM
Thanks, this worked for me.

jhoweaa
1 Jun 2015, 6:13 AM
Interesting, today it seems to be working. Perhaps I just had something cached.

madaras_adrian
9 Jun 2015, 3:26 AM
Thanks for the override.

rsnickell
16 Jun 2015, 5:27 AM
Recent update to Chrome has fixed this issue in 43.43.0.2357.124m works with submenus.

madaras_adrian
16 Jun 2015, 5:29 AM
Will confirm when I will have the new Chrome Update and new Chrome webview on mobile.

mcouillard
16 Jun 2015, 4:37 PM
Yes, latest stable release of Chrome seems to have solved it. Tested using Extjs Docs menu and the fiddle here:https://www.sencha.com/forum/showthread.php?301116-Submenus-disappear-in-Chrome-43-beta&p=1101291&viewfull=1#post1101291

jamil.isayyed
23 Jul 2015, 9:55 PM
any updates on this bug ??

madaras_adrian
23 Jul 2015, 10:34 PM
Still waiting as well.

Gary Schlosberg
24 Jul 2015, 1:24 PM
I'm using Chrome 43.0.2357.134 and I'm not seeing the submenu issue anymore. With which version are you seeing it?

madaras_adrian
7 Aug 2015, 12:13 AM
Tested with Version 44.0.2403.125 (64-bit) of Google Chrome and still without this override it's not working:



Ext.define('XXX_Mobile.controller.override.Application', {
override: 'XXX_Mobile.controller.Application'
});

Ext.define('Override.util.PaintMonitor', {
override : 'Ext.util.PaintMonitor',

constructor : function(config) {
return new Ext.util.paintmonitor.CssAnimation(config);
}
});

Ext.define('Override.util.SizeMonitor', {
override : 'Ext.util.SizeMonitor',

constructor : function(config) {
var namespace = Ext.util.sizemonitor;

if (Ext.browser.is.Firefox) {
return new namespace.OverflowChange(config);
} else if (Ext.browser.is.WebKit || Ext.browser.is.IE11) {
return new namespace.Scroll(config);
} else {
return new namespace.Default(config);
}
}
});

madaras_adrian
6 Sep 2015, 11:23 PM
I can confirm that it is working now. Thank you

maciertos
15 Sep 2015, 10:52 AM
All perfect!! Thank you very much!

dougbieber
3 May 2016, 1:57 PM
Just to let you know, these workarounds are fine for the version of EXTJS which we're using (4.2.2). However, disappearing submenus occur in 6.0.2 and it doesn't matter which browser you're using.-Doug

Gary Schlosberg
3 May 2016, 3:06 PM
Thanks for letting us know. This is a copy of the original test case:
https://fiddle.sencha.com/#fiddle/19p1

I'm not seeing the issue so far. Do you see the issue in that test case?