Found while trying to test #1807692: Introduce a column synchronization capability and use it to translate alt and titles through the image field widget
Reproduced in clean new 8.x.

Problem/Motivation

Nice browse and upload widget is there when 1 image allowed.
Widget goes away when multiple images are allowed.

Proposed resolution

(description of the proposed solution, the rationale behind it, and workarounds for people who cannot use the patch)

Remaining tasks

  • locate cause
  • add test
  • propose fix

Steps to reproduce

  1. clean install
  2. create an article, see the image upload widget
  3. structure: article
  4. manage fields: edit image
  5. (global) field settings: change allowed values to 2 (or 4 or whatever). save.
  6. create an article, see the image widget is gone.

User interface changes

No. Just a fix.

API changes

No API change expected.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

YesCT’s picture

Issue tags: +Needs tests
FileSize
69.13 KB

I might have the component wrong...

Here is a screenshot.
multiplevalueimage-2013-01-09_0332.png

YesCT’s picture

next steps (in any order):

  • check that other field types work or not for multiple values (text field, file, number, other?)
  • get someone else to reproduce
  • find a recent commit that may have caused this (unless someone has a good guess: find a commit where this worked in the past, do git bisect)
swentel’s picture

Don't see any problems here ..

Screen Shot 2013-01-09 at 13.51.26.png

swentel’s picture

Component: field_ui.module » field system
YesCT’s picture

I double checked again. did a sudo rm -r sites; git checkout sites; git checkout 8.x; git pull --rebase; drush -y si ...

the screenshot in was in Firefox 17.0.1
Can still reproduce that

In Chrome
I get something different, almost the same, but with a arrow showing the field is collapsed.

Here is a screenshot of Chrome (Version 23.0.1271.101)
cardinality-chrome-s01-013-01-09_0906.png

It expands ok, but after adding each image it "jumps" back to collapsed.

swentel’s picture

So that's a DETAILS problem (the new tag instead of fieldset - see #1168246: Freedom For Fieldsets! Long Live The DETAILS.), not a field problem. Could be that this version of firefox has a bug maybe ..

sun’s picture

Component: field system » file.module
Status: Active » Needs review
FileSize
1.47 KB

There are two bugs here:

1) Details are always collapsible. #collapsible is obsolete. The rendering should no longer account for a potential FALSE value. (The remaining clean-up will happen in #1852104: #type details: Remove #collapsible property)

2) File module implements a custom multiple field widget behavior and manually implants theme_details() as a #theme_wrappers — that's completely missing all other element type properties of #type 'details', which means that collapse.js doesn't get loaded at all.

Status: Needs review » Needs work
Issue tags: -Usability, -Needs tests, -browser compatibility

The last submitted patch, drupal8.file-multiple-details.7.patch, failed testing.

swentel’s picture

Status: Needs work » Needs review
Issue tags: +Usability, +Needs tests, +browser compatibility
swentel’s picture

That indeed fixes it, and I was wondering about that #collapsible thing, good to know about the other issue :)

If this comes green and YesCT confirms, this is RTBC from me.

YesCT’s picture

Status: Needs review » Reviewed & tested by the community

I've delayed, but I can verify that it fixes it in both firefox and chrome.

it also still applies.

YesCT’s picture

Status: Reviewed & tested by the community » Needs work

The last submitted patch, drupal8.file-multiple-details.7.patch, failed testing.

YesCT’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
Issue tags: +Usability, +Needs tests, +browser compatibility

The last submitted patch, drupal8.file-multiple-details.7.patch, failed testing.

YesCT’s picture

Issue tags: +Needs reroll

tagging for reroll (reroll doc: http://drupal.org/patch/reroll)

swentel’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
853 bytes

Rerolled after the #collapsible cleanup happened.

YesCT’s picture

Issue tags: -Needs tests, -Needs reroll

This might not need tests since it was browser dependent.

If someone knows how tests should be done, please provide some details to help direct that.

(untagging needs tests and also needs reroll since that was done. thanks. :) )

catch’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs tests, +Needs reroll

Was this really browser dependent? I'd expect the missing #type => details to have an impact on the HTML so presumably we could test for the HTML with it and that'd fail without?

sun’s picture

Status: Needs review » Reviewed & tested by the community

Yes, this bug depends on the browser being used, due to native browser support differences for details, which circles back into #1839158: Replace collapse.js with a proper polyfill for <details> — that is, because the render element manually specifies a #theme_wrappers of 'details', which means that it goes through the appropriate theme function, but alas, just without any element type defaults + pre_render/preprocessing.

This is simply a brain-dead oversight in form declaration. It's like forgetting to fill out the x in 1 + x = 2.

Due to that, I disagree with the need for tests here. Stuff like this just simply happens during refactoring.

Just simply consider the phpDoc for such a test:

/**
 * Tests that the file field widget uses a details element.
 */

Oh, wow. ;)

catch’s picture

Status: Reviewed & tested by the community » Fixed

Hmm OK if we had browser acceptance tests we could actually test that nicely but agreed that makes no sense with simpletest. Committed/pushed to 8.x.

Status: Fixed » Closed (fixed)

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

Gaelan’s picture

Issue tags: -Needs reroll