#foswiki 2013-10-17,Thu

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
orevanyone familiar with plugins for tinymce? I've got my code working to block large inline image pastes, but it only works once and freezes the editor window after it blocks something. http://fpaste.org/47344/19687511/ [00:02]
pharveybtw in TMCE 4.x this callback has been removed :/
can you set some breakpoints to see where it's hanging?
I don't see any obvious fault
[00:05]
........... (idle for 50mn)
gac410pharvey, found one issue in tmce 4.0.8 on fw. It inserts a blank line between %TABLE{}% and |the|table| breaking the association. [00:57]
pharveyhm
I do keep intending to patch up selenium haha
[01:08]
gac410And in general I've noticed, even in current code, if the topic ends with a table, there is no way to position the cursor after the table to extend the topic. :P Poking at that a bit now. [01:09]
Well, a brute force, blindly append the topic with <p class="foswikiDeleteMe">&nbsp;</p> seems to work, and doesn't cause creeping topic length [01:16]
Whoops... even current TMCE / Wysiwyg is accumulating blank lines between %TABLE% and | table| :( [01:22]
orevpharvey: the hooks has been added back in the git version: http://www.tinymce.com/develop/bugtracker_view.php?id=6110 [01:22]
gac410no, blank lines are not being inserted. ... except once. :P [01:26]
..... (idle for 21mn)
bah... this is a mess. Blank lines inconsistently are inserted after %TABLE statement, and on occassion, remove prior to the %TABLE, But not consistent at all :( [01:47]
pharveythis really needs the selenium tests [01:56]
........................... (idle for 2h10mn)
gac410pharvey, yes. I added translator tests of the exact page I've been having trouble with, but ROUNDTRIP is solid. So it's something tmce is doing with the html
For now I'm abandoning it. :(
[04:06]
.... (idle for 17mn)
***gac410 has left [04:23]
....................... (idle for 1h50mn)
ChanServ sets mode: +o CDot [06:13]
.................. (idle for 1h26mn)
ChanServ sets mode: +o CDot [07:39]
.......... (idle for 46mn)
MichaelDaumTWiki finally implemented TopicTitle
see http://twiki.org/cgi-bin/view/Codev/TopicDisplayName and http://twiki.org/cgi-bin/view/Codev/ShowTopicTitleInLinks
http://twiki.org/cgi-bin/view/TWiki/VarTOPICTITLE
their specs are: store the TopicTitle in a Title formfield if present; fall back to storing it as a TITLE preference variable
DBCachePlugin does the same but uses a TopicTitle formfield or a TOPICTITLE preference variable
... which is better imho as a Title formfield conflicts with lots of DataForms using Title as something completely different rather than the display name of a topic. E.g. when describing a person Title is something like Mr, Mrs, Dr, Prof or the like.
I haven't looked at the code they added to TWiki-Core to implement it.
as this is yet to be released as TWiki-6.0
I wonder though whether they deal with topics that already have a TOPICTITLE preference setting but receive a DataForm later on having a TopicTitle formfield.
DBCachePlugin covers these cases by migrating the store location in both directions ...
(1) adding a form (2) removing a form
Foswiki-core should add the notion of a TopicTitle as well moving the feature from DBCachePlugin into the core
with NatEditPlugin being part of the core we are all set in this respect.
hower there's another important point: renaming a topic
there are a few overlapping use cases here
(1) create a topic using a TopicTitle only and deriving a TopicName from it (wikification) (2) change the TopicTitle of an existing topic (3) change the TopicName (4) change both TopicTitle and TopicName
jquery.wikiword helps with (1) and is the default in NatSkin. so you don't have to think about proper WikiWords anymore
with regards to (2) when people change the TopicTitle a lot over time while the TopicName stays as it is (stable urls) the danger is that both deviate from each other too much
in this case (4) the UI needs a way to rename the topic matching the TopicTitle changes as close as possible, again using jquery.wikiword.
this is covered in NatSkin as well: two input fields - one for the TopicTitle, one for the TopicName - and a checkbox "derive from TopicTitle" which automates the generation of a TopicName matching the TopicTitle as close as possible according to the definition of a WikiWord
there's a case (5) to consider: autocompletion when selecting a topic
what users see is the TopicTitle. wikiapps however operate on TopicNames
so autocomplete and select+values interfaces used to chose a topic need to display the TopicTitle while selecting the TopicName as the actual value
this needs changes to any "pick from list" interface to handle topic parents or the like
The TopicTitle proposal logically leads to WebTitles: the display text when linking to SomeWeb.WebHome
both TopicTitles and WebTitles play an important role in breadcrumbs
having worked with TopicTitles in various wiki apps yet another use case came up: the TopicTitle being agregated by two or more other formfields of a DataForm.
in some wiki apps it makes more sense to automate the TopicTitle using two or more formfields
I hope to cover this use case better than before with the next release of MoreFormfieldsContrib which will come with an autofill formfield type. this one will be auto-filled by concatenating formfields of the same DataForm being saved.
this works out fine in the current implementation but hasn't been fool-proven in real-world projects yet.
so a TopicTitle formfield of type autofill will then be able to generate proper TopicTitles - and thus link texts - based on more complex scenarios.
[08:25]
MichaelDaum added above to http://foswiki.org/Development/TopicDisplayName [09:06]
.......... (idle for 45mn)
***ChanServ sets mode: +o pharvey [09:51]
....................................... (idle for 3h10mn)
ChanServ sets mode: +o gac410 [13:01]
................... (idle for 1h33mn)
gac410jast: MichaelDaum ... I'm running configure under Chromium Version 30.0.1599.66 (225456) - bi-weekly release from google. Initial load of bin/configure, took 4 seconds [14:34]
jastI don't think initial load ever was an issue (though of course one could argue that 4s is a bit excessive already) [14:35]
gac410Longest event was a "Parse HTML" which was mostly jquery callbacks.
And was 1.7 seconds.
[14:35]
MichaelDaum+1 jast
gac410, when you pocke around a bit more, have some extra plugins and the like, you will see.
[14:35]
gac410This is trunk.foswiki.org. What plugins cause the problem then?
TBH I can live with 4 seconds for a configure tool that I use once a month at most. I just don't get that there's a problem.
If it was 40 seconds, then yeah that's an issue, but 4?
[14:37]
MichaelDaumsorry that we didn't get into more detail and create a proper bug report [14:39]
gac410If we can identify what triggers the issue, maybe we can fix it rather than throwing out the whole baby [14:39]
MichaelDaumyea that would be good [14:40]
gac410Either that or it's browser specific. I know that Timothe spent a lot of time making IE not choke on it. [14:40]
MichaelDaumI thought it was all too obvious that this is far too sluggish to be ready for prime time.
as jast said as well. the thing validates user inputs every now and then. this is too expensive and renders the tool next to useless.
instead, it should validate all settings in one single transaction.
[14:41]
gac410Foswiki.org/bin/configure took 11 seconds just now, compared to 4 on trunk [14:42]
MichaelDaumusers will understand that a dedicated validate operation takes a bit. but not when all of the cfg is submitted to a non-fcgiable perl cgi app.
submitted quietly in the background
[14:43]
gac410TBH I'd much rather have it tell my I've borked a regex when I tab off the field, rather than waiting to the very end. If there is a field you don't want to validate, just remove the auto* flag from the config.spec [14:43]
MichaelDaumI am sure Timothe could have elaborated whats going on in more detail if he still was here
sorry I have to wander off and can't give you more details of my conplains atm.
[14:44]
gac410Any field with the little @ spinner shown to the right will be auto-validated on loss of focus. I think initially we can just tune what ones are auto-validated
The rest are validated on the "Configuration Audit" page, so *both* solutions exist. We need to figure out how to optimize that.
anyway, if you can identify what is causing the issues, I'll look at them. I've probably spent the most time on the internals of configure, as I was his "beta" for all his work.
[14:45]
MichaelDaumgac410, okay firing up configure(trunk)...takes 5s
security and authentication > Httpassswd-Encoding ... clicking on "use default" browser freezes for 10secs or so.
[14:55]
gac410From speedtracer, the bulk of the time is HTML Parse, with jquery.1.8.2 callbacks [14:56]
MichaelDaumno transaction with the backend [14:56]
gac410wow... hang on let me see if I can recreate with speedtracer [14:56]
MichaelDaumah there was a POST
timed it more precisely: the actual POST took only 427ms. but up to that point the browser freezes up solid (tooltip not disappearing, no scrolling)
[14:57]
gac410Yeah, speedtracer show 7 seconds in javascript callback [14:59]
MichaelDaumit seems to be stuck gathering all of the cfg before sending it over
in the end my configure then sends over 321713 bytes
as a result of a single "set to default" click
then, it does no more than toggling the value of an input field.
[14:59]
gac410Yeah, configure always - even in the old configure, always sends the entire configuration back on post. [15:01]
MichaelDaumno. not like this.
it obviously has to send over the new cfg, but not on every "set to default" click
[15:01]
gac410I assume a "save" would have the same effect, posting the "form" Right, old configure only did that once on save. I'm not sure why it does it on every set. [15:02]
MichaelDaumTimothe took the "ajaxify configure" a bit too far as it seems. [15:03]
gac410That's not an auto-validated field, so there is no reason for it to post at all. I'm guessing it's a bug
The only things that should post AFAIK are fields that ask the server to validate the value.
[15:03]
MichaelDaumthere are not much are there?
even regexes can be tested clientside
[15:04]
jastcan they? [15:05]
gac410right. I think some are validated client side. Number ranges, etc. [15:05]
MichaelDaumtry {new Regex("foobar")} [15:05]
gac410Not sure about regexes. [15:05]
jastregexes are fairly difficult to test for sensibleness
and perl's regex syntax is much richer than javascript's
[15:05]
MichaelDaumI'd rather not take a full roundtrip to the server just to test a regex
it can test it together will all of the rest in one transaction and then produce a feedback on possible errors
[15:06]
gac410This is a difference in the javascript engine, There is no delay whatsoever clicking use-default / use-stored on firefox.
I't pretty much instanteous
[15:08]
jastyes, we know :) [15:08]
MichaelDaumgac410, let me check. [15:08]
jastpoint is, if it only works properly with one particular browser engine, it's not really ready for prime time [15:09]
gac410No... point is we need more eyes, and people with other environments to figure out what's wrong. The solution is not to throw it out because one dev in the project didn't recreate the issue on a particular browser [15:09]
MichaelDaumgac410, right. firefox is okay. it still POSTs all of the cfg to the backend [15:10]
jastwe should *also* fix its POSTing all data on pretty much any change [15:10]
MichaelDaumchrome however, goes to sleep *before* sending the actual request. [15:10]
gac410I'm not sure why it posts the whole config. It's difficult because the backend doesn't have any way to store a "candidate" config where you could just post changes. [15:11]
MichaelDaumis there a need for statefull? [15:12]
gac410Unfortunately with the way the config hash is loaded, expanding or not-expanding references to other hash entries makes it difficult. [15:12]
MichaelDaumthere are two separate issues here:
(1) the code before sending the cfg over to the server to might be bad in such a way that it does not perform on chrome
[15:12]
gac410There are lots of inter-related config entries. So changing A can trigger an error with B, all over. [15:13]
MichaelDaum(2) in general there are too many of those transactions with the backend. [15:14]
gac410and 1) could be the client, or it could be a jquery bug, Is JQuery 1.8.3 the best version for configure to use? [15:15]
MichaelDaumI don't think this is jquery related
what I would look for is array and copy operations
[15:15]
gac410ah... yes, it probably copies the config hash for the post. But why would it work on FF, not on chrome (webkit?) That sounds like one of his IE problems, where it went off into lala land on a array [15:16]
MichaelDaumspeculation [15:17]
gac410I agree with (2) ... but if (1) wasn't an issue, we could probably live with (2) and have another project sometime post 1.2, to make configure restfull, and move the "candidate config" from client to server. [15:18]
MichaelDaumI just recently had difficulties the other way arround with events being fired much too often on firefox.
we can't live either with (1) or (2)
again speculation wrt (1)
it needs a proper investigation instead
[15:18]
gac410Yes. agreed. [15:20]
MichaelDaumthere might be one silly thing freaking chrome
once fixed everybody is fine.
[15:20]
gac410y. I'll poke at it a bit. [15:20]
MichaelDaumhave to run and see my son on his boxing training. til tomorrow. [15:21]
gac410cool. Have fun! [15:21]
......... (idle for 40mn)
Here is the offending statement, scripts.js line 1728. Takes around 11 seconds
$('form').find(":input:enabled").not(':file,:submit,:reset,:button').each(function (index)
It appears to be the act of finding the first input:enabled field that is not file, submit.... It takes 11 seconds to hit a breakpoint on the firs line of the inline function.
[16:01]
............. (idle for 1h0mn)
I think your 1 & 2 above are indeed the root cause. 1.2 configure maintains the state of the "un-saved" configuration in a session variable. But it works with the old 1.x client model, and posts the entire form.
If we could update the session variable with just the modified field, then the code to find all input fields and post them would be unnecessary. And that would play to what others have asked for - a restful configure to allow a single config variable to be updated.
[17:06]
Hm... Other than chrome having a performance issue, I think we have a bug, in that most fields should NOT post when changed. [17:18]
So we are not honoring ... # **SELECTCLASS Foswiki::PageCache::DBI::* FEEDBACK=AUTO DISPLAY_IF {Cache}{Enabled}**
This one for example is a legitimate request, The FEEDBACK runs a validation that the selected perl dependencies are installed and returns an error if not installed
But there is absolutely no reason to post action=feedbackUI when FEEDBACK is not set.
[17:25]
....................... (idle for 1h52mn)
jast: I've got a partial fix. At least *every* field doesn't autocheck. I think there was some "old code" that auto-checked every field. I deleted it, since the auto-check fields have on-click handlers
There is still a huge performance problem on chrome, but only when a post is required, and now that's only on the autocheck fields, or button press, not every field.
[19:17]
jastnice... that's a decent step forward :) [19:32]
gac410Just checked it in. Need to regenerate the .gz version of the script (make_gz in resources directory or re-pseudo-install) and refresh js on the page or clear cache.
http://trac.foswiki.org/changeset/16938
I'm afraid solving the performance issue may be "above my pay grade" :)
[19:33]
jastif I had to guess, it's probably webkit not implementing the pseudo-selectors efficiently [19:37]
gac410yeah, that seems to be what I'm seeing in some google searches. [19:37]
jastwe may want to try a more recent jquery, too [19:37]
.................... (idle for 1h37mn)
gac410Well, I'm about to revert. I don't get it. I tested this multiple times, and everyting was fine, and now suddenly, no autochecking at all. Must have been something stale in the cache [21:14]
foswiki_irc3version.pm
getting this error : version version 0.77 required--this is only version 0.74
[21:19]
gac410Did you install a new foswiki or extension? [21:21]
foswiki_irc3new [21:21]
gac410Are you able to install CPAN modules? Foswiki needs an updated version that is shipped in more modern versions of perl. [21:21]
foswiki_irc3our unix admon is having trouble finding the 0.77 version of version.pm
yes the admin can
[21:21]
gac410Any version 0.77 or newer [21:22]
jastinstalling via CPAN should automatically get you 0.77 or newer [21:22]
gac410https://metacpan.org/module/JPEACOCK/version-0.9904/lib/version.pm
yes, updating version to latest cpan version should get you the latest. Latest is 0.9904
[21:23]
foswiki_irc3ok .. thanks i will pass on the info [21:24]
gac410the require statement defines the minimum required version, not the exact version. [21:28]
jast, tried another checkin for the autocheck issue. This seems to work, but I said that last time too. :P [21:40]
jastfingers crossed :) [21:41]
gac410I also upgraded to JQuery 1.10.2 + upgrade-plugin ... it works, but it's just as slow. [21:43]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)