For example at
/admin/reports/dblog
The "Filter log messages" and "Clear log messages" fieldsets do not open when clicked.

There are no JavaScript errors. The problem appears to be something within:

  // .wrapInner() does not retain bound events.
  var $link = $('<a class="fieldset-title" href="#"></a>')
    .prepend($legend.contents())
    .appendTo($legend)
    .click(function () {
      var fieldset = $fieldset.get(0);
      // Don't animate multiple times.
      if (!fieldset.animating) {
        fieldset.animating = true;
        Drupal.toggleFieldset(fieldset);
      }
      return false;
    });

The click event is never triggered.

Firefox 27 is currently in the beta channel, and will be released publicly within the next few weeks. This bug is specifically seen on OSX Mavericks, but I'm guessing that the OS is not relevant.

CommentFileSizeAuthor
#9 core-seven_theme_collapsible_firefox-2158353-9.patch371 bytesRadioActiv

Comments

ansorg’s picture

ansorg commented

Confirmed. But no, it's not the javascript. It does not even get this far. It's the rendering of the link in the legend element - it does not appear as a link. I have no idea what could cause this.

But you can use build in "Inspect Element", navigate to the span within the legend and remove the "fieldset-legend" class. The link becomes a link now and works as fieldset toggle.

<legend><span class="fieldset-legend"><a class="fieldset-title" href="#"><span class="fieldset-legend-prefix element-invisible">Anzeigen</span> Filter</a><span class="summary"></span></span></legend>

This is probably something in the Seven 7.23 theme. When using Bartik for admin, all fieldsets do work.

ansorg’s picture

ansorg commented
Component: javascript » Seven theme
lewisnyman’s picture

lewisnyman
he/him
commented
Status: Active » Closed (won't fix)

You're right, it doesn't work in Firefox 27 beta 2. I also tested it in FIrefox 26 and Firefox Nightly and it seems to be working fine. I think we're better off submitting a report on bugzilla.

dalin’s picture

dalin
he/him
Primary language English
Location 🇨🇦, 🇲🇽, 🌍
commented
Status: Closed (won't fix) » Active

I don't think we can close this until:
1) We understand what is going awry.
2) A bug is filed with Mozilla and linked to from here.

This has the potential to affect a lot of Drupal sites if FF27 is released publicly without a fix.

lewisnyman’s picture

lewisnyman
he/him
commented

Ok that makes sense, let's keep it open so we can track is this problem does get fixed by Mozilla.

RadioActiv’s picture

RadioActiv commented

It appears to be a z-index issue with the fieldset-legend span that is used. Adding "z-index: 1" on the fieldset-legend class fixes the problem for me on FF29 (nightly).

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

I'm on latest fx x64 nightly (currently 29.0a1) on Win7 x64 and this has been driving me crazy for about a month now. Specifically, it manifests itself in the update.php after pending db updates and I can neither see what is about to be updated nor the results messages after the update runs (other than it was a success).

If the fix suggested here to modify the z-index is something acceptable, then please do so and commit it to the next dev. Mozilla is notorious for taking waaaay too long to fix things.

Did I mention that it drives me crazy?!?

lvthunder’s picture

lvthunder commented

Firefox 27 is set to be released the week of February 4, 2014 according to https://wiki.mozilla.org/Releases

RadioActiv’s picture

RadioActiv commented
StatusFileSize
new core-seven_theme_collapsible_firefox-2158353-9.patch371 bytes

Patch attached. This minor change fixed it for me in FF Nightly (v29.0a1).

RadioActiv’s picture

RadioActiv commented
Status: Active » Needs review
klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented
Status: Needs review » Reviewed & tested by the community

This is a one-liner. It's been working fine for me since #6 so RTBC unless someone objects.

neclimdul’s picture

neclimdul
He/Him
commented

Seems like this is an upstream but though. Has anyone figured out a simple case we could give to Mozilla?

lewisnyman’s picture

lewisnyman
he/him
commented

RTBC++ but let's keep this issue open after commit to figure out if we can provide a usecase

David_Rothstein’s picture

David_Rothstein commented

Has anyone filed a bug with Mozilla yet?

For example, is this the same issue discussed at https://bugzilla.mozilla.org/show_bug.cgi?id=942341 (or related to it)? It sounds from that issue that they are aware there is potential fallout with fieldsets in Firefox 27 but are looking for feedback on how serious the problem is... Obviously, we have an example here that will affect a significant number of sites across the web.

If we don't have a simple pared-down example to send them, could we at least point them to http://simplytest.me and then an appropriate page post-install (maybe admin/reports/dblog?) as a quick way to see the bug in action?

Committing a workaround to Drupal core isn't going to be that effective since most sites won't get the new code before the new Firefox gets released anyway. So this regression should really be fixed upstream if at all possible.

RadioActiv’s picture

RadioActiv commented

As far as that Mozilla bug goes, in comment 11:

One problem with "preserving the old behavior" is that I don't see how to do that and simultaneously support *scrolling* fieldsets with abs-pos children in any kind of sane way.

and subsequent comments, they don't seem to want to fix it. Since this only affects one of our core themes, not all (or even most) themes, I think that our best option is to make the change in Drupal core, the change doesn't appear to hurt compatibility with other browsers and users at least have a possible fix...instead of "we think it's an upstream bug, so they'll fix it eventually". To be clear, I'm not claiming that Mozilla isn't wrong, I'm just saying that for the sake of users, let's patch it and we can revert if/when they fix this...

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

What @RadioActiv said. Mozilla is notorious for not fixing things for really long times (way longer than Drupal :P ) - especially when things are complicated. Lets not torment our users when we can simply roll a one-line fix that as @RadioActiv said doesn't break things for other browsers.

RadioActiv’s picture

RadioActiv commented

Based on the level of review that has happened on this one line CSS patch, I'm saying we call it good, and ask that it be committed to 7.x-Core trunk. I haven't tried in Drupal 8, so I do not know if this affects it, if anyone knows if this is also an issue in Drupal 8, please comment and if possible add a patch.

RadioActiv’s picture

RadioActiv commented
Title: All collapsible fieldsets broken in Firefox 27 » All collapsible fieldsets broken in Firefox 27(beta), 28 (aurora), and 29a (nightly)

Updating title to indicate that issue is affecting Firefox Beta, Aurora (pre-beta), and Nightly (alpha); so that it is clear that if not resolved for Firefox version 27, it will also affect other future versions.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

...I just tested all D7 and D8 core themes over at simplytest.me (the fieldsets at /admin/reports/dblog) and the only one that seems to be having the issue is Seven 7.x. So, I'm not sure how easy it would be to convince mozilla people that this is a generic vs a specific theme issue. I'm 99% sure they'll throw the ball right back at us :/

RadioActiv’s picture

RadioActiv commented

Based on it working on other [current] browsers, and that it is "fixed" (based on @klonos) in Drupal 8, I think that Drupal 7.x Core was relying on a defect in Firefox's/Others rendering that has been fixed in Firefox 27, and will likely be fixed in the next release of other browsers once Firefox 27 is made the Stable release. Even if we think we're in the right on this one, it's not worth an unusable user experience to try and fight it. In the end it will only hurt us.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

No, no I don't think that the issue ever existed in D8 ...at least nobody reported it. I simply tested just to make sure because of your comment back in #17.

lewisnyman’s picture

lewisnyman
he/him
commented

It's not as if we are using an non-standard CSS in the Seven theme. It's definitely a bug, we just need to figure out how to recreate it outside of Seven. I'll play around in JSfiddle later

rocallahan’s picture

rocallahan commented

I'm the Mozilla developer involved. Can you give me a link to an example of this issue?

Absolute positioning, and are not properly specified and all browsers do insane things in different situations (try making with a overflow:auto in Chrome and scroll it, for example) so it's not clear what "correct" means in general. But we definitely don't want to break a lot of content.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

@rocallahan: I have no generic JSfiddle example, but what brakes things in Drupal can be seen here. Simply click "launch sandbox" and then "log in". Once you are in, you'll find example non-working fieldsets in places like these (from the navigation menu at the top of the page):

  • Reports -> Recent log messages: both the "Filter log messages" as well as the "Clear log messages" fieldset.
  • Configuration -> Account settings -> Manage display (tab): "Custom display settings" fieldset at the bottom of the page
RadioActiv’s picture

RadioActiv commented

@klonos, and @rocallahan...I'm not sure that Drupal is either right, or wrong in the current CSS implementation, but one of the two projects needs to fix this before the current Firefox beta is moved to stable; otherwise we both risk end-user backlash. Either it's "Mozilla: I updated my Firefox, and now Drupal doesn't work", or it's "Drupal: I updated my Firefox, and now I can't use anything in Drupal's admin pages".

We either need to agree on which side is right, or commit a [possibly] temporary Drupal core fix that allows our users to be able to administer their Drupal 7.x sites....

Personally, I think that this should be fixed by FF/Mozilla, since it works in the current stable Firefox, and works in Chrome/Chrome beta/Chromium, and IE....And I think Opera too, but I'm not sure if people still use Opera...

rocallahan’s picture

rocallahan commented

This is definitely a Mozilla bug. I'm producing a fix in https://bugzilla.mozilla.org/show_bug.cgi?id=960277. For Firefox 27, I intend to just back out the patch(es) that caused this regression.

David_Rothstein’s picture

David_Rothstein commented

Thanks so much, rocallahan! (And thanks to everyone who has been testing on this end too.)

Once that's in we can hopefully close this issue as soon as someone does a final test with the latest Firefox 27 codebase.

rocallahan’s picture

rocallahan commented

BTW for future reference, we do fix bugs :-). Some bugs may lie unfixed for a long time for various reasons (some good reasons, some bad), but a bug that makes Drupal unusable with Firefox is definitely going to get our attention. So please file! I wish we'd known about this one earlier.

neclimdul’s picture

neclimdul
He/Him
commented

Just so its clear, Drupal is equally guilty of old issues/bugs. ;) Thanks for the quick response and sheparding our problem into the right place!

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

@rocallahan: TL;DR: Sorry if I offended you in any way :P

...I've been using firefox since 0.8 and thunderbird since 1.0.8. I actually have local backups of the latest minor versions of all major versions of both + all a copy of their Greek versions of them (as soon as they were available: for fx 0.8 and for tb 1.5.0.14). I also was from the first to start using nightlies and x64 versions of them as soon as they became available and started kicking tires. My bugzilla profile dates from 2009-02-11!

My point is that I was from the first avid beta testers actively participating in testing and trying to help as much as I could with troubleshooting issues. So yes, you do fix bugs - I give you that. In fact I never said that you don't fix bugs. What caused my frustrated comment back in #16 though is the fact that -as you very politely put it- "bugs may lie unfixed for a long time". Exactly what I said too:

Mozilla is notorious for not fixing things for really long times...

Anyways, we all do what we can and we know how open-source/FOSS works. Not that here in Drupal we are much better either. We all do our best because after all we're human. Cheers ;)

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented
Component: Seven theme » theme system

I just had this happen to a custom theme too, so this is not limited to only core Seven.

RadioActiv’s picture

RadioActiv commented
Component: theme system » Seven theme

This is an issue that is caused by a browser change; the only way we can "fix" it other than the FF change is to modify our/contrib theme's CSS. AFAIK, there's nothing we could do the the core theme system that would be able to fix this for all themes. Since we can't fix contrib themes with a core change, I'm setting this back to the "Seven theme" component. If other themes are affected by this FF change, then an issue should be opened for their maintainer to fix...

David_Rothstein’s picture

David_Rothstein commented

Hm, so this is still happening, then (even with the latest Firefox 27 code)?

Sounds from above like the patch that caused this problem was going to be rolled back for Firefox 27...

Can anyone confirm?

dalin’s picture

dalin
he/him
Primary language English
Location 🇨🇦, 🇲🇽, 🌍
commented
Status: Reviewed & tested by the community » Fixed

Confirmed fixed on
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Firefox/27.0

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

AFAIK form.inc is responsible for rendering fieldsets. Right? Isn't there some default css/js loaded in order to achieve the expand/collapse functionality? If there is, then we could add this change (z-index: 1; for fieldset .fieldset-legend) and we'd fix this globally for all themes. Just thinking out loud here.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

...confirming fixed since at least Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20140128031716 CSet: 4da3e21a0e5f

I simply hadn't restarted my browser for some days now. Thanx ;)

Status: Fixed » Closed (fixed)

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