This is due to the fact that the collapse/expand is handled through jQuery (common.js).

There are several other features in 1.3 which rely on javascript, e.g. captcha refresh, filter highlighting, etc.

I think we should require javascript in 1.3.

the collapse_api seems to be a not so good implementation
it actually creates two divs, one filled with content, and other empty. With javascript one or the other is show/hidden.
Why not use only one inner div and show/hide this one, keeping the outer frame?
A disable js browser would show the div anyway, also good for accesibility.

Another side effect, which affects the normal js-enabled case:
The filter section, even when collapsed, shows an input field for text search.
Being two different divs, if you write something in the search field, and then collapse/uncollapse, the field is hidden along with its parent div. (and the field now showed is not the same we were typing into)
this can be confusing (if ever noticed)

please try this css fix:
https://github.com/mantisbt/mantisbt/pull/664

if you write something in the search field, and then collapse/uncollapse, the field is hidden along with its parent div. (and the field now showed is not the same we were typing into)

nice catch... probably deserves its own separate issue, as it would not be so trivial to fix (and is definitely not addressed by your CSS tweak)

Why not use only one inner div and show/hide this one, keeping the outer frame?

Not sure I'm following you here, can you please clarify ?

I wonder whether instead of fixing this, we should make a change that will hide the MantisBT interface and show a message that Javascript must be enable for MantisBT to work.

show a message that Javascript must be enable for MantisBT to work

Imho, not for the reason of this bug. I mean: any UI improvement has been delayed to a future next major release, so let that decision be justified with an actual UI improvement. So, being consistent, since 1.3 will not have major javascript intensive functionality, its worth polishing this kind of bugs, to keep the ui "as is" for the next release cycle.

More to this, i think this is a regression of the CSS changes, 1.2 has the same messed collapse_api but somehow the visibility is set right on page load.

Not sure I'm following you here, can you please clarify ?
I mean: a more sane way to do the open/collapse would be by toggling the visibility of the actual contents, not by maintaining two different section containers.

[div "frame"]

[div "inner"]

...content...

[/div]

[/div]

inner.hide() / inner.show()

While having a single inner div with contents as you suggest would probably be fine in most cases, it would only work for "basic" collapsed sections, i.e. those which only contain the "-" button and the section's title.

How would you suggest we handle special cases, e.g. the sponsorship section (the title changes when it's collapsed to show the total amount) or the filters div ?

You can't do much on the internet these days without javascript. Lets not get stuck in last decade world. We have already made the decision that in 1.3 javascript is not optional. Let's just advertise this when the browser doesn't have it enabled. This will enable all plugins and core to just know that this is the case and develop accordingly without "it is just this thing that is broken".

As mentioned in the PR https://github.com/mantisbt/mantisbt/pull/664, the proposed fix basically disables access to the expanded filter box when js is disabled, so it is not a good solution to the problem.

We have already made the decision that in 1.3 javascript is not optional

While I don't disagree with this, I don't recall a formal decision.

Let's just advertise this when the browser doesn't have it enabled
In any case, thats a good point.
For example, add a non-intrusive message warning that JS is disabled and some functionality may be degraded as a result

How would you suggest we handle special cases, e.g. the sponsorship section (the title changes when it's collapsed to show the total amount) or the filters div ?
A show/hide logic for the collapsing system should be driven by classes, and content shlould also be uniqe.
In the sponshorsip case, at first sight looks like its unnecessary to have that differentiation on title ¿why not show all the info, always?
.. and if really needed, type it with meaningful classes.
Eg: all ".collapsed-hide" elements will be hidden, be it the iner div, or a [span] part in the title.
You could even have a ".collapsed-show" class for content that should be visible only when the section is collapsed

the proposed fix basically disables access to the expanded filter box when js is disabled, so it is not a good solution to the problem.
look at the updated PR. The api is messier than i had thought.

cproensa, I opened 0020224 to track the collapse API issues, let's continue this discussion there, and keep this issue focused on fixing the duplicated sections (even if it's just a temporary workaround)

With regards to the JS detection, we have to think of a proper way to do this from PHP.

this is a neat trick:
https://css-tricks.com/snippets/javascript/css-for-when-javascript-is-enabled/

hiding stuff with jquery startup may cause some flickerig. Remember the attempt to move scripts to footer made it even worse.

However, JS detection should not be needed from server. If it is needed, maybe the design is wrong?

Please keep in mind: There are a large number of corporate users who object to a reliance on javascript for proper operation. It interferes with security settings and other add-ons like screen readers for the blind.
The keyword /accessibility/ should be written in capital letters - especially for a bugtracker, as we want to get EVERY bug from every user!
For sure, you can realise cool things with js, but it should also work without.