Dropbutton library is only loaded on cache rebuild

This happens even using bartik and I think that happens with any theme..
The problems seems to be in views + render cache; if you disable the render cache (using cache.backend.null) or you disable the views module, dropbutton.js is attached to the page and dropbuttons are displayed properly. Not totally sure but the problem seems to be how views renders fields in FieldPluginBase::advancedRender()

On my tests, this only happenned on /admin/content

also /admin/people is affected. I think that every page generated by views in which there are dropbuttons is affected

moving to views.module component

We seriously need a test for that, but maybe more important, get a more sane architecture in place for things which are renderer maybe or maybe not inside a render context.
You should be able to write APIs which can be used outside of a render context, otherwise all your render related APIs will be bound in its usage to render API, not just internally,
and this is IMHO horrible on the longrun for maintainability.

This regression was introduced by #2511472: Refactor all usages of drupal_render()/Renderer::render() that break #2450993. That, in turn, was a spin-off/child issue of #2450993, and at #2450993-33: Rendered Cache Metadata created during the main controller request gets lost, the change to StylePluginBase that causes this problem was introduced.

The root cause:

• Views' render pipeline is string-based (not render array-based), because of legacy reasons and because it needs to be able to support any output format, not just HTML. This means that StylePluginBase needs to be string-based.
• This means that for attachments to bubble, StylePluginBase needs to use render(), and not renderPlain(). This used to be the case until #2511472: Refactor all usages of drupal_render()/Renderer::render() that break #2450993. (Clearly we're missing some test coverage there.)
• So, the solution seems simple: change renderPlain() back to render(). This will bubble onto the main rendering context.
• But! Non-HTML views may very well not be using the regular render pipeline. And then calling render() will cause exceptions.
• Fortunately, solving #2351015: URL generation does not bubble cache contexts required us to add a RendererInterface::hasRenderContext() method. Which we can now handily exploit to use either render() or renderPlain().

Yes, this is horrendous. But given the facts (Views' render pipeline was not updated in Drupal 8 to be render array-based, nor do render arrays support any format other than HTML, we have hasRenderContext() because of deficiencies in the URL generation APIs), this seems like a fair compromise. Views is likely the only piece of code that needs to ever do this.

You should be able to write APIs which can be used outside of a render context, otherwise all your render related APIs will be bound in its usage to render API, not just internally,
and this is IMHO horrible on the longrun for maintainability.

Agreed that these are important goals. We won't achieve them in 8.0.0. We must achieve them in 9.0.0. We should starting to achieve them in 8.x.0.

#8 patch can be applied and fix issue

Conflict between RTBC and 'Needs tests'

Working on a test

Test only + test & patch added

Nice test! I've also reviewed the patch, so I'm restoring it to RTBC.

Let's get this in asap. We shouldn't ship RC1 without this.

Just added some docs because otherwise no one will remember why this test is being done.

Committed decb9b1 and pushed to 8.0.x. Thanks!