Last modified: 2014-07-08 13:09:13 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 T67687, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 65687 - mw.loadData can be used to pass data between #invoke's by reading frame arguments
mw.loadData can be used to pass data between #invoke's by reading frame argum...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Scribunto (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Brad Jorsch
:
Depends on:
Blocks: 65258
  Show dependency treegraph
 
Reported: 2014-05-23 17:33 UTC by Jackmcbarn
Modified: 2014-07-08 13:09 UTC (History)
3 users (show)

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


Attachments

Description Jackmcbarn 2014-05-23 17:33:36 UTC
Create the following as Module:LoadData/data:
return { mw.getCurrentFrame().args[1] }

Create the following as Module:LoadData:
local p = {}
function p.main(frame)
return mw.loadData('Module:LoadData/data')[1]
end
return p

Create the following as Module:LoadData/doc:
{{#invoke:LoadData|main|some data to share}}
{{#invoke:LoadData|main}}
{{#invoke:LoadData|main}}

This will return the following:
some data to share
some data to share
some data to share

This indicates a break of isolation between the different calls to #invoke.
Comment 1 Brad Jorsch 2014-05-23 17:52:51 UTC
Ugh.

Inside mw.loadData, we should have mw.getCurrentFrame() return a frame with no args and no parent, and probably either nil or the name of the module passed to mw.loadData for getTitle(). Can you think of any other fields in the frame that would be problematic?
Comment 2 Jackmcbarn 2014-05-23 17:55:51 UTC
That sounds like it should be good, but could any games be played with newChild and/or getParent to defeat that?
Comment 3 Jackmcbarn 2014-05-23 17:58:13 UTC
(Specifically, mw.getCurrentFrame():newChild{blah blah...}:getParent() is what I'm worried about leaking the "real" current frame.)
Comment 4 Brad Jorsch 2014-05-23 18:01:02 UTC
(In reply to Jackmcbarn from comment #3)
> (Specifically, mw.getCurrentFrame():newChild{blah blah...}:getParent() is
> what I'm worried about leaking the "real" current frame.)

No, that'd return the same as mw.getCurrentFrame(). There's a test for this in Scribunto_LuaCommonTests::testFrames().
Comment 5 Jackmcbarn 2014-05-23 18:07:06 UTC
I'm saying that when this is changed, that test should also happen within a loadData environment, to make sure it doesn't get inadvertently broken in that case.
Comment 6 Gerrit Notification Bot 2014-07-07 16:58:47 UTC
Change 144478 had a related patch set uploaded by Anomie:
Improve mw.getCurrentFrame handling

https://gerrit.wikimedia.org/r/144478
Comment 7 Gerrit Notification Bot 2014-07-07 18:26:52 UTC
Change 144478 merged by jenkins-bot:
Improve mw.getCurrentFrame handling

https://gerrit.wikimedia.org/r/144478
Comment 8 Gerrit Notification Bot 2014-07-07 20:15:52 UTC
Change 144511 had a related patch set uploaded by Jackmcbarn:
Improve mw.getCurrentFrame handling

https://gerrit.wikimedia.org/r/144511
Comment 9 Gerrit Notification Bot 2014-07-08 13:09:13 UTC
Change 144511 merged by jenkins-bot:
Improve mw.getCurrentFrame handling

https://gerrit.wikimedia.org/r/144511

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


Navigation
Links