Wikimedia Bugzilla is closed!

Looks like it's mysteriously been fixed this afternoon, after an update on TWN a couple mins ago I'm no longer able to reproduce.

And now I'm getting it consistently again (last night and this morning), I spoke too early.

Same on Chromium and over HTTP, just verified on mediawiki.org too which is at 1.20wmf11 (6108192).

Most probably caused by Gerrit change #17683, as this is the only merge on that day in the affected area. Adding Helder to CC.

Steps to reproduce:
1. Ensure logged in at https://translatewiki.net.
2. Go to https://translatewiki.net/wiki/User_talk:SiebrandLqtTest
3. Click "Start new discussion"
4. Subject: Test
5. Contents: Test
6. Click "Save Page"
7. Click "Summarize"
8. Contents: Test
9. Click "Save page"

Observed:
a. Pop up appears stating "You cannot post a blank message"
b. Once clicks "OK" on the pop up, the page is saved anyway.
c. No JS errors observed in Firebug.
d. Adding an edit summary does not change observed behaviour.

Expected:
* Page is saved without warning "You cannot post a blank message"

The message is shown because when the code from window.liquidThreads.handleAJAXSave is executed the "text" in the test
> $j.trim( text ).length == 0
is actually undefined. But this was already the case on Gerrit change #17940, which came before Gerrit change #17683 on
https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/extensions/LiquidThreads+-owner:L10n-bot,n,z

Indeed, if I do
> cd extensions/LiquidThreads/
> git review -d 17940
and follow the steps from comment 5, I get the error
Uncaught TypeError: Cannot call method 'trim' of undefined

In both cases the fact that the text is undefined do not prevent the code from another function from saving and reloading the page (even if the [[translatewiki:MediaWiki:Lqt-empty-text]] is displayed), because none of lines which contains
> e.preventDefault();
is ever executed.

The reason for "text" being undefined is the line
> text = editform.find('#wpTextbox1').val();
which depends on the existence of some "editform". But it is defined as
> var editform = $j(this).closest('.lqt-edit-form');
and while summarizing a thread there is no element with class "lqt-edit-form".

It seems this specific bug could be fixed by replacing the line which defines the text by
> text = $j('#wpTextbox1').val();
(because there should be at most one element with this id on the page). But there will be the problem of "editform" being empty...

Is bug 40083 related? It's been recently reported by a casual user and I'm reproducing it consistently.

I confirmed that this is still reproducible today per instructions on comment #5 .

Removing as a blocker since blocking the 1.21wmf2 deployment won't help matters.

(In reply to comment #9)
> Removing as a blocker since blocking the 1.21wmf2 deployment won't help
> matters.

Sigh, didn't the WMF once say that the Wikimedia projects which chose LQT were going to get life support for it? I think you should notify them that you don't guarantee LQT won't be broken by updates, ie that LQT is completely unsupported.

(In reply to comment #10)
> I think you should notify them that you don't
> guarantee LQT won't be broken by updates, ie that LQT is completely
> unsupported.

How on earth do you get from not being able to guarantee that it won't get broken to it being completely unsupported?

(In reply to comment #11)
> How on earth do you get from not being able to guarantee that it won't get
> broken to it being completely unsupported?

Well, if it gets intentionally broken and upgrades are performed however broken LQT can get, I call that being unsupported. Reversing the question, what kind of support does WMF offer to Wikimedia projects using LQT?

This may be fixed with https://gerrit.wikimedia.org/r/#/c/27844/

Note: taking issues off the blocker list don't diminish their priority.  It just means we're not going to hold a particular version deployment hostage over it.

(In reply to comment #13)
> Note: taking issues off the blocker list don't diminish their priority.  It
> just means we're not going to hold a particular version deployment hostage over
> it.

The difference is subtle: given the nature of LQT, this means that any and all bugs affecting it will rot forever and get worse at each update.
Also, no need for hostages: is it really impossible to revert changes which are known to break stuff and deploy them only *after* they've been fixed? 

<rant>From a user perspective it's really impossible to understand what the purpose of continuous integration is, if nothing can stop known bugs from getting deployed. Erik asked people to file major bugs against LQT a year ago http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/56008 , but it's obviously useless; I do it only for masochism and tracking-addiction.</rant>

This bug also happens if you reply to a message by opening the reply link in a new tab, e.g. <User:Nemo_bis/monobook.js]]_28760">https://translatewiki.net/w/i.php?title=User_talk:Nemo_bis&lqt_method=reply&lqt_operand=28760#[[User:Nemo_bis/monobook.js]]_28760> (I had to do so because often the text area for the reply or new thread doesn't open inline even after many reloads).

There is a not-too-huge patch (+18, -5) waiting for two weeks now in https://gerrit.wikimedia.org/r/#/c/27844/ - could somebody review it?

Milestone missed.

I'm trying to review this but when trying to save the summaries I actually get this in /var/log/apache2/error.log:
[Sun Feb 17 13:43:40 2013] [notice] child pid 7278 exit signal Segmentation fault (11)

Not sure what I did but it seems to be working now.

Merged.

(I should probably add that the segfault issue I was having was both with and without the patch, and I can't reproduce it anymore.)