Script content loss

Bug #1377401 reported by Vadim Peretokin on 2014-10-04
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mudlet
Fix Released
Critical
Chris

Bug Description

People are reporting that their script are getting wiped on 3.0.0-alpha[1] and beta[2].
This is a regression in 3.0 as it doesn't happen in 2.1. Steps to replicate:

- Select a script with your mouse
- Navigate up or down at least 1 item with your arrow keys
- Switch to any other tab
- Switch back to the original script

Result: original script is blank.

See http://forums.mudlet.org/viewtopic.php?f=7&t=4610&p=21779#p21778 for the original report.

[1] http://forums.mudlet.org/viewtopic.php?f=5&t=4598&p=21563#p21563

[2] http://forums.mudlet.org/viewtopic.php?f=7&t=4610&p=21775#p21774

description: updated
Colin L Crowley (sanaki) wrote :

I can confirm I've had this happen in beta via some unknown other means. I was rapidly searching things while switching between aliases, triggers, scripts, and keys and when I was done, I checked my miller's script section to find it was blank. I don't use arrow keys to navigate. A basic profile rollback fixed it fine of course.

Changed in mudlet:
importance: High → Critical
status: New → Confirmed
Chris (chrismudlet) wrote :

This bug is caused by mCurrentScript not being updated on keyboard navigation.

Chris (chrismudlet) wrote :

This also affects EVERY view. You can do the same logic with triggers and it'll delete the script.

Chris (chrismudlet) on 2014-12-30
Changed in mudlet:
assignee: nobody → Chris (chrismudlet)
status: Confirmed → Fix Committed
Changed in mudlet:
status: Fix Committed → New
Vadim Peretokin (vperetokin) wrote :

It manifests itself in another way now: when you create a new trigger, the trigger you had previously selected gets its name, script and other propreties wiped (but not the trigger patterns).

Stephen Lyons (slysven) on 2015-01-05
Changed in mudlet:
status: New → Confirmed
Chris (chrismudlet) wrote :
Changed in mudlet:
status: Confirmed → Fix Committed
Vadim Peretokin (vperetokin) wrote :

It manifests itself through the search window now in the gamma preview:

Navigate to a script, enter something in the search box that you know will find hits in a different category(variables, aliases, etc), then just click on the variable/alias/trigger/etc and the script value of the old script you had selected will be replaced by the contents of whatever it is that you clicked on in the search results box (http://forums.mudlet.org/viewtopic.php?f=5&t=4684&p=22266#p22264).

Changed in mudlet:
status: Fix Committed → Confirmed
Vadim Peretokin (vperetokin) wrote :

Including a video demonstrating the problem. The scripts content gets replaced with mmp.swim() which is from the trigger.

It won't directly solve the problem but it might help to trace the flow,
put a boiler plate qDebug("<name of function><list of values of
(significant) arguments>") enabled by a global or class member boolean,
at the start of "every significant method" in the dlgTriggerEditor class
(?) and track the program execution (will record the "slot" methods as
well) I'm sure something will be surprising - that was how I found that
double clicking on the treewidgets also called the single click slot -
twice!

(Might want to discount Focus events from the "every method" list above
- that does gets rather spammy if we can be certain that is not the/a
problem area.)

On 07/01/15 21:57, Vadim Peretokin wrote:
> Including a video demonstrating the problem. The scripts content gets
> replaced with mmp.swim() which is from the trigger.
>
> ** Attachment added: "Screencast 2015-01-08 07:56:21.mp4"
> https://bugs.launchpad.net/mudlet/+bug/1377401/+attachment/4293744/+files/Screencast%202015-01-08%2007%3A56%3A21.mp4
>

Vadim Peretokin (vperetokin) wrote :

Agreed - that's what I did. I ended up with a loop through that didn't seem
fixable.

On Thu, Jan 8, 2015 at 9:54 AM, Stephen Lyons <email address hidden>
wrote:

> It won't directly solve the problem but it might help to trace the flow,
> put a boiler plate qDebug("<name of function><list of values of
> (significant) arguments>") enabled by a global or class member boolean,
> at the start of "every significant method" in the dlgTriggerEditor class
> (?) and track the program execution (will record the "slot" methods as
> well) I'm sure something will be surprising - that was how I found that
> double clicking on the treewidgets also called the single click slot -
> twice!
>
> (Might want to discount Focus events from the "every method" list above
> - that does gets rather spammy if we can be certain that is not the/a
> problem area.)
>
> On 07/01/15 21:57, Vadim Peretokin wrote:
> > Including a video demonstrating the problem. The scripts content gets
> > replaced with mmp.swim() which is from the trigger.
> >
> > ** Attachment added: "Screencast 2015-01-08 07:56:21.mp4"
> >
> https://bugs.launchpad.net/mudlet/+bug/1377401/+attachment/4293744/+files/Screencast%202015-01-08%2007%3A56%3A21.mp4
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1377401
>
> Title:
> Script content loss
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mudlet/+bug/1377401/+subscriptions
>

Stephen Lyons (slysven) wrote :

Would I be right in thinking that this thing "like Topsy" has got too
big (and complex) to track everything that is going on.

You might like to check, but I think all the OptionsArea stuff is just
useless cruft (all dlgOptionsArea*.h; mpOptionsArea* pointers in
dlgTRiggerEditor and all the options_area_*.ui forms) this is not doing
anything to harm or cause the problems but they do not seem to be adding
anything to the project in this area AFAICS.

I vaguely recall AC suggesting that he wanted to go over the trigger
editor - I take it that he is not currently able to add any insight into
this matter.

I'm guessing but I'm beginning to suspect that each of the
{Action|Alias|Keys|Scripts|Triggers}MainArea classes (and possibly the
Vars one as well) will have to gain an isDirty flag which is set when
any content (after we have picked out what *is* content - does
"mpActionsMainArea->lineEdit_action_icon" count, for instance) is
modified and use that to determine whether to save the current
content... (that is compounded by the complexity of whether the current
content is a "group" or "item" {branch vs leaf node???})

I'm guessing we want something for the delta version if not before, 8-(

On 08/01/15 00:04, Vadim Peretokin wrote:
> Agreed - that's what I did. I ended up with a loop through that didn't seem
> fixable.

Chris (chrismudlet) wrote :
Changed in mudlet:
status: Confirmed → Fix Committed
Changed in mudlet:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers