If I use Firefox (35.0.1) on OS X Yosemite to edit a view, for example /admin/content, and click on the add button in the field section, and click anywhere in the modal Firefox hard crashes - completely locks up.

The conditions to cause this appear to be:

  • Firefox 35
  • OS X
  • Using seven as the admin theme
  • CSS enabled

Firefox profile output

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Bug, because it turns on your fan
Issue priority Critical, because you might use a laptop, which will things
make hard to type on the longrun.
Disruption Should not cause disruption
CommentFileSizeAuthor
#21 2423781.21.patch437 bytesalexpott
#20 2423781.18.patch488 bytesalexpott
#5 Screen Shot 2015-02-10 at 20.48.56.png213.86 KBalexpott
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue summary: View changes
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

This is not just views it also occurs when adding a new block in the block ui.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

It appears to be something recursive that sometime eventually firefox manages to get out of.

neclimdul’s picture

neclimdul
He/Him
CreditAttribution: neclimdul commented

Just as another data point I was not able to reproduce this in Linux. Don't see how something like this would be OS specific but thought I'd log my observations in case it is.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue summary: View changes
FileSize
Screen Shot 2015-02-10 at 20.48.56.png213.86 KB

I've disabled all the extensions and it still occurs. I managed to create a js performance profile but it does not really help (me at least).

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
Issue tags: +JavaScript

Let's tag it, so nod_ will see it.

cosmicdreams’s picture

cosmicdreams CreditAttribution: cosmicdreams commented

Tested on Firefox 35.0.1 (on Windows 7)

I didn't notice any hangs but did notice lag when I attempted to add an image to the textarea with CKEditor.

@alexpott can you please:
1. Open Firefox's devtools (F12 on windows)
2. Navigate to the Debugger
3. Click the gear on the far right, and enable "Pause on Exceptions"

What is the function / line that the exception is happening on?

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

@cosmicdreams not seeing an exceptions - all I'm seeing is a hang - massive use of cpu - and eventual success.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

Also this is fixed by reverting #2392887: Update JS lib: jQuery to 2.1.3

cosmicdreams’s picture

cosmicdreams CreditAttribution: cosmicdreams commented

That leads me to believe that this is jquery's fault.

Edit: trying to track down the source of the problem....

cosmicdreams’s picture

cosmicdreams CreditAttribution: cosmicdreams commented

@alexpott : And this happens when you click the "Add content" button on the /admin/content page (which doesn't seem to open a modal) instead of the ckeditor's add image modal?

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

@alexpott : And this happens when you click the "Add content" button on the /admin/content page (which doesn't seem to open a modal) instead of the ckeditor's add image modal?

It happens if you add a new field in views

davidhernandez’s picture

davidhernandez
Primary language English
Location USA
CreditAttribution: davidhernandez commented

Commenting just to say I'm also seeing this. Views, block settings. Views seems to be the worst. With the block settings form I just had to wait a few seconds, but the Views "add field" locks up Firefox.

davidhernandez’s picture

davidhernandez
Primary language English
Location USA
CreditAttribution: davidhernandez commented

I noticed the problem doesn't happen in Stark or Bartik, only in Seven.

nils.destoop’s picture

nils.destoop CreditAttribution: nils.destoop commented

Confirming this problem.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue summary: View changes
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue summary: View changes

Disabling CSS also fixes it.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
CreditAttribution: larowlan commented

Seeing this too, spinning rainbow, eventually comes good, could be the auto sizing JavaScript, the examples listed all use that. So CSS changes would definitely impact that.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

From alex screeshot, seems jQuery.event.fix triggers layouts all over the place https://github.com/jquery/jquery/issues/1746

Not sure what to do here, can't replicate. Any big CSS change on dialogs lately?

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Status: Active » Needs review
FileSize
2423781.18.patch488 bytes

So the patch attached actually fixes the problem!

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
FileSize
2423781.21.patch437 bytes

And here is a better fix. I have no clue as to why :(

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

Chrome works fine with the patch in #21 applied.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

It indeed does it for me as well.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented
Issue tags: +CSS

I guess dawehner can RTBC, happy with it but no clue what's going on. Maybe ping one of the CSS people to make sure it's all good with them.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
Issue summary: View changes

GIven my approved knowledge of css by nod_ :P

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
Status: Needs review » Reviewed & tested by the community

.

davidhernandez’s picture

davidhernandez
Primary language English
Location USA
CreditAttribution: davidhernandez commented
Component: ajax system » Seven theme

I think it should be sent to LewisNyman to look at. It's a CSS change in Seven, plus he might have a better idea of what is causing it.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

The overflow: hidden; was added in the upgrade of jQuery UI from 1.10.2 to 1.11.2 - see #2403269: Update to jQuery UI 1.11.2.
What is interesting is that jQuery-ui has just removed the overflow: hidden - see https://github.com/jquery/jquery-ui/pull/1439... after adding it in https://github.com/jquery/jquery-ui/pull/1092

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

We added the seven specific styling in #2113911: Modal style update

LewisNyman’s picture

LewisNyman
he/him
CreditAttribution: LewisNyman commented
Issue tags: +frontend

I can confirm that this patch does not cause a visual regression in Seven. RTBC++

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

If I remove both overflows then firefox still hangs - we're going to have to be careful when we upgrade again.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

Can we document this?

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

I'm not sure where to document this - the danger comes when we upgrade jquery ui

LewisNyman’s picture

LewisNyman
he/him
CreditAttribution: LewisNyman commented

Maybe place a comment above the change?

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented

Happy to add that on commit. Suggested comment?

cosmicdreams’s picture

cosmicdreams CreditAttribution: cosmicdreams commented

/** Note: Modifying the overflow css rule has been found to cause performance issues on Firefox. See:
**/

LewisNyman’s picture

LewisNyman
he/him
CreditAttribution: LewisNyman commented

How about:

jQuery UI modals crash in Firefox unless overflow is set to hidden, see: https://www.drupal.org/node/2423781.

  • webchick committed cf7898e on 8.0.x 
    Issue #2423781 by alexpott, dawehner, cosmicdreams, davidhernandez,...
webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Status: Reviewed & tested by the community » Fixed

Works for me!

Added that and committed and pushed to 8.0.x. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

pivica’s picture

pivica CreditAttribution: pivica at MD Systems GmbH commented

There was a good reason why jQuery team removed that jQuery overflow hidden in the first place. We now have a same problem in #2508830-6: Various UI problem with autocomplete select control and ideally removing that overflow hidden from seven would be the best option for fixing it.

I don't want to reopen this issue for now until more people take a look.

Can somebody with OS X and FF maybe check is FF crashing still when that overflow hidden is removed from seven css? If FF is still crashing we will need to find some other solution for absolute positioned controls inside jquery dialog.

s_leu’s picture

s_leu CreditAttribution: s_leu at MD Systems GmbH commented

I opened a follow up for #2508830: Various UI problem with autocomplete select control here: #2535122: Autocomplete suggestions in modal clipped due to overflow: hidden.

IMHO fixing the bug described in #2535122: Autocomplete suggestions in modal clipped due to overflow: hidden, which occurs not only on OS X and in FF but in many browsers, is more important than fixing that very special case for FF on OS X ;)

So i agree to remove the overflow: hidden from seven again, also added this as proposed solution in the new issue.

sasanikolic’s picture

sasanikolic CreditAttribution: sasanikolic at MD Systems GmbH commented

I reverted this patch and tested on Mac OS-X Yosemite (10.10.3) and Firefox 39. No Firefox crashes for me with this configuration.

For #2535122: Autocomplete suggestions in modal clipped due to overflow: hidden the suggestions didn't load for me, although I created lots of content with devel generate.