athenurlauber wrote:

I think I've improved my diagnosis:

The bug manifests itself when the embedded table has more columns than the table in which it's embedded.

In other words: the sortability property of headers in the main ("enveloping") table remains in tact as long as the embedded table doesn't have more columns than the table in which it's embedded.

As soon as number of columns in the embedded table is greater, the headers in the main table are no longer rendered as sortable, whereas headers in the embedded table are (although the embedded table is not defined as "sortable" at all).

Tagging with need-unittest; this'll need some qunit tests to verify a fix.

two things:

1: what is the EXPECTED result in both situations ? (not fully clear to me from your report)
2: we actually use this somewhere ? And isn't it a better idea to change that usage in stead perhaps ?

Might be related to the multi row header

Fixed in r105727

athenurlauber wrote:

Ah - fixed? Please translate the technocracy. As far as I can see, nothing has changed. Please (again) take a look here for a demonstartion:

http://en.wikipedia.org/wiki/User:Dan_Pelleg/Sandbox/Sortability_bug

As to your questions (ah - did you read my posts? Did you take a look at the link I provided and at its source?):

1. The expected result is, that columns defined as sortable indeed always be rendered as sortable, insead of losing their sortability if one of their headers happens to contain an embedded table that happens to have more columns than it's "mother".

2. Yes, the reason I found the bug was because a table I'd created suddenly went awry without any edits having been made to it. If it's really necessary, I'll explain why I created this kind of table. Is it really necessary? Roundabout solutions can often be found, is this a reason to leave this silly bug unattended to?.

You can take a look at the "real usage" site here (I've found a roundabout solution for the time being - an additional layer of embedded tables, yuck):

http://he.wikipedia.org/wiki/%D7%A9%D7%95%D7%A8%D7%A9_%D7%9E%D7%97%D7%95%D7%9E%D7%A9#.D7.93.D7.95.D7.92.D7.9E.D7.90.D7.95.D7.AA

Yes, fixed in the software. Software doesn't get deployed immediately however.

Yes i did read, but this is a complicated situation, so the more you tell a developer, the better he can figure out what problem you have exactly.

1: so you are only concerned with the sorting capability breaking on the PARENT table right ?

2: Well depends on what you call a bug. If you take a pillow and hit something hard a couple of times, i'm sure you can break the pillow. Is it desirable however to make the pillow out of kevlar for that reason ? For instance fixing this probably negatively affected performance for table on Internet explorer 6. Trade offs are always made.

athenurlauber wrote:

1. Yes - the embedded table isn't even defined as sortable, and unless it has more columns than its parent, the sortability also isn't inherited. Which is good.

2. Ok, I'll explain: within a sortable table, I have one column that contains tables organizing its contents in a visually clear and consistent structure (this column doesn't need to be sortable). This column's header contains a table too, which parallels the embedded tables' structure, and whose cells can thus refer to their counterparts within the tables listed below. A perfectly reasonable usage.

3. I assume this bug arouses from a logical flaw in programming. If instead of "sticking a band aid" on it you'll figure out the flaw and "cure the infection at the root", I'm sure it won't compromise performance, but will more likely enhance it. Or am I missing something and this isn't a bug at all, but rather a programmer's intentional "compromise", designed to enhance performance but assuming nobody will ever need to embedd a table in a header?

4. As I mentioned (maybe I wasn't clear enough), the bug didn't exist before the sorting button's appearance was changed. A clue to figure out who messed what up back then?

1: Ok, then that is fixed now.

2: ok

3: You understand incorrect on all accounts. Doesn't matter :D

4: They are entirely different implementations. They were bound to have some inconsistencies between them. The new one is much more flexible and future proof than the old one.

I notice this was reopened..

Closing again as fixed, because the bug is fixed. Deployment towards the english wikipedia, will take a few weeks/months as usual for non-critical bugs.

Added a unit test for this problem in r105773

athenurlauber wrote:

Thanks for attending to the problem and for the information.

Purely out of curiosity: What kind of malprogramming produces such a weird "phenotype"? Embedded non-sortable tables "stealing" sortability away from their mothers by having a larger number of columns?

Could you maybe please try to outline how this works (in non technical terms)?