These pieces are only relevant when the new "inlineDescription"
feature is enabled. In other words: This can't have an effect on
the old dialog.
The 2.5em left and right are from an old styling when the
parameter pages have been indented.
Change-Id: I022b0dd94ee66f7de114c055c3f453317a7f6131
This sorting algorithm was introduced via Ic6bc348 (T274544). Note
there is no index parameter in the .onReplacePart() handler at this
point. When a part was moved, it was removed and simply appended
to the end. The additional sorting was needed to move it back to the
correct position.
This changed a few days later via Iafe29f1. There is now an index
parameter. The .onReplacePart() handler does the same as before, but
puts the part at the correct position right away. The additional
sorting is pointless since then.
The removed code alone is responsible for 1/3 of the total blocking
time when the template dialog opens.
Bug: T296335
Change-Id: I6c3fa70b532d34cd29d59c3b48ab81ebf608d548
onReplacePart is being called when templates are being moved up or down.
To prevent that the multipart message gets moved around passively e.g.
by one element being added above it, this patch adds it to the top after each movement.
Bug: T292829
Change-Id: I946c9bc4ba5e1d261aefbb28a8c642bb58964842
We forgot change the way that message is build while adding the link
in 07f105fd7. Now it gets parsed correctly and the link will open in
a new tab.
Bug: T284985
Change-Id: I1ed9dfdafd08d08c5aff45f4b74c540b35ec14a1
This is only relevant with the old design. It's only noticable when
a field shows all 3 action icons: info, raw wikitext mode, and
trashcan. The last icon can wrap to the next line when the screen
is very narrow.
I tried to apply nowrap, but this causes other style issues.
Removing the arbitrary width allows the action container to be
as wide as it needs to be. I can't tell why this restriction was
there. It is in no way necessary, as far as I can see. I can only
guess it's a temporary artifact from when the dialog was designed.
Bug: T296730
Change-Id: I77129ccc3afe002ba697b1787b41d0a388d5f4b8
This does have a significant impact on the performance of the
template dialog. Not only on construction time, but also because
MWExpandableContentElement objects do some quite expensive
.updateSize() calculations the moment they become visible.
I profiled a template with (only) 200 undocumented parameters.
Construction time goes down from ~600ms to ~520ms. The mentioned
.updateSize() runtime goes down from ~300ms to ~10ms.
Bug: T296335
Change-Id: I280f814e722b299aae0ec6a5a2fa59292e3e5887
Remove using of User:getOption since this method will be hard-deprecated. Now it is soft-deprecated
Bug: T296083
Change-Id: Ic177a170fd3c72ebbb80da60dc8597285ab5e023
This doesn't have much of an impact on performance according to my
profiling. But I think it's worth it nevertheless. The idea is to
skip that <div> entirely when it's empty.
Bug: T296335
Change-Id: Id155725fbc2e3453acc1cdcabfdc2d687285d694
