Last modified: 2014-02-12 23:37:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T38279, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 36279 - [SF] <internalerror_text> on page save
[SF] <internalerror_text> on page save
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
SemanticForms (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Yaron Koren
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-26 21:26 UTC by badon
Modified: 2014-02-12 23:37 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
One of the users provided a screenshot of the error (88.31 KB, image/png)
2012-04-26 21:26 UTC, badon
Details

Description badon 2012-04-26 21:26:14 UTC
Created attachment 10478 [details]
One of the users provided a screenshot of the error

This bug is still occurring with Semantic Forms 2.4.2, SMW 1.7.0.2, and MediaWiki 1.18. I've noticed the error message:

<internalerror_text>

in earlier versions of Semantic Forms, but I could not figure out what caused it, since the error would go away when I tried reproducing it. Now, I've gotten several reports about this error, and I have a guess about what's causing it. The error only seems to occur when different users are saving form data simultaneously. 

Also, I suspect it might be related to usage of variants of <unique number;start=1> in the form's info tag, like this:

page name=<unique number;start=1>

That might explain why we have &lt; and &gt; in the error message, if "unique number;start=1" is the bit that returns the error message.

This bug I've been studying and reported here produces the same error message as in the report for Bug 30844, but I think the cause is different. It has been difficult to reproduce because there needs to be a lot of form page saves in a short period of time, and probably by more than 1 or 2 users. It might also be a quirk related to slow database responsiveness, but I'm not sure about that yet.

In almost all cases, a second attempt at saving the form data succeeds. There was one case where a user had clicked on many #autoedit links very quickly, and while those were doing their thing, another user complained about 3 successive failed form save attempts.

That's all I've been able to determine so far.
Comment 1 badon 2012-05-27 05:36:26 UTC
I've discovered another possible clue for this bug. I'm still not sure what causes it, but when it happened simultaneously with several similar preloaded forms, refreshing only one of them resolved the problem and caused all of the others to begin working again too. 

Bug cause possibilities:

* Maybe the bug is somehow related to the browser state, either with cache or JavaScript? 

* There's a preloaded time field that updates with the browser refresh. 

* The create page form's {{{info}}} tag has a <unique number> component in the page name= parameter. Maybe several create page forms being loaded at the same time causes a page name collision, in some circumstances?
Comment 2 badon 2012-05-27 08:11:25 UTC
I am using Opera. One user with Google Chrome has reported that reloading the form does not get around the error. Another user with Firefox has reported that simply reloading the error message page will cause the page save to succeed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links