@Spuds sounds like the ios browser doesn't fire the "click" event?
This.
The admin is not shown because the admin panel is not really that mobile-friendly.
IIRC the up/down buttons were removed because there were complains them being in the way? Or maybe my memory is wrong...
update on this point:
REopening the menu make it work , so you have to open then close then open again.
I see that RTL support isn't really getting enough attention here , i feel like a bug collector >:(
but anyway here is another bug :
the attach button , doesn't work in elkarte default rtl template , to reproduce the issue in [this forum] just switch page direction in your browser while you are on reply or new post , the hidden browse button is shifted to the left of the drop attachments area
Additionally the drag and drop will not work in [my forum]
Most likely those that tested it didn't see the problems. If you do not use the software every day in a certain condition is quite hard to spot the issues, and TBH, the RTL is not really something I can use for more than 15 minutes.
You are now testing it and reporting bugs, that's how it works. ;)
@Spuds I think the only way to have it overlap properly the a tag is to use some js trickery... do you have any idea? I gave it a try but could put anything together... :'(
ROFLMAO. So it's your turn, is it? Been there, done that. You have my sincere condolences.
I know I'm not Mr. Potato Head, but a simple RTL flip shouldn't require javascript. If you need RTL javascript I'd say something is wonky.
hmmm that doesn't sound good
@Antechinus , so as a previous victim ;D any idea how long would it take before the agony stops
Two options there:
1/ When you run screaming out the door.
2/ When the frigging thing gets to a stable release.
The problem is not just an RTL flip, the "click" area is actually a transparent input the if forced to overlap an a tag. The a tag contains the text, the input reacts to the click and does the upload.
The way it is currently (i.e. css) may break in any case the size of the string (either the one inside the a tag, or outside) is not similar to the original English one (if the text inside is larger then part of it will not overlap, if the text before is shorter it may not overlap, if it is too long it may overlap the wrong part, etc.).
Ah. Ok. Haven't ever looked at the code there. Sounds like a brittle solution though. Isn't there a cleaner way of doing it?
I'm sure there is a better way, but what that is I don't know.
I think originally we just had it as link text, but the issue was no one noticed it was a link and felt forced to use the D&D interface. We made the current changes to make it look like a standard input button. How it arrived at the current markup .... I may have been able to explain that 3 years ago but now I have no idea .... I'm just a simple starch !
This is rather weird. needs head scratch smiley
Ok, so it's an input now, but originally was just an anchor? And an anchor can be styled just like an input, or like anything else for that matter, and being an inline element should automatically handle rtl languages and automatically adjust its length to suit whatever text for whatever language. So at the moment I don't see why there's a need to complicate matters. Has anyone tried it with just a suitably styled anchor lately?
You need the input to catch the "files" attribute and start the upload (I think), so you need the input, but you use the anchor to give it text and style.
Mostly guessing. :P
But there aint no anchor there. I checked teh markups. :P
Ok, so you need the input. Righty. Then why did someone say it used to be a link? needs head scratch smiley again
I understand that file uploady stuff usually uses an input, so am not flabbergasted that one is necessary. I'm just sure (might be wrong, but don't think so) that there would be a way of incorporating the little mongrel without jumping through hoops.
I'll pig around with it on local and see if I can get it to behave.
sorry to drop this in the middle of your geeky talk :P
here an update on this other "previously reported issue" from chrome console , using mobile emulator :
1:
(Link-4593) 2:
(Link-4591) Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.
getXMLDocument @ script.js:67
grabJumpToContent @ script.js:1087
onfocus @ VM1470 index.php?topic=18983.0:321
Not really a performance problem given what it is, but replace the function grabJumpToContent(elem) with the below to clear it up.
/**
* This function will retrieve the contents needed for the jump to boxes.
*
* @param {type} elem
*/
function grabJumpToContent(elem) {
this.elem = elem;
getXMLDocument(elk_prepareScriptUrl(elk_scripturl) + 'action=xmlhttp;sa=jumpto;xml', onJumpReceived);
}
/**
* Callback function for loading the jumpto box
*
* @param {object} XMLDoc
*/
function onJumpReceived(oXMLDoc) {
var aBoardsAndCategories = [],
i,
n,
items = oXMLDoc.getElementsByTagName('elk')[0].getElementsByTagName('item');
for (i = 0, n = items.length; i < n; i++)
{
aBoardsAndCategories[aBoardsAndCategories.length] = {
id: parseInt(items[i].getAttribute('id')),
isCategory: items[i].getAttribute('type') === 'category',
name: items[i].firstChild.nodeValue.removeEntities(),
is_current: false,
childLevel: parseInt(items[i].getAttribute('childlevel'))
};
}
for (i = 0, n = aJumpTo.length; i < n; i++)
aJumpTo[i].fillSelect(aBoardsAndCategories);
// Internet Explorer needs this to keep the box dropped down.
this.elem.style.width = 'auto';
this.elem.focus();
}
Ok, I may not have a full understanding of the problem yet as I haven't done any live testing, but I've been checking out the markup for the file upload stuff.
You can use a styled anchor for the fake button, but there's not much point. A span would do just as well, and would mean you don't have to include a redundant href. The anchor or span, and any text inside an anchor or a span, should automatically sort itself for RTL. If it doesn't, something has been bungled somewhere. For that matter you could even use a div or several other tags and get the same result. It mattereth not.
It should also be possible to put the input inside the span, with right and left positioning set to 0, or with max-width and min-width set to 100%, and overflow set to hidden. That way it should always cover the text no matter what language was being used, and shouldn't need any special treatment for RTL.
Regarding styling: if you're going for a normal buttony look there it might be an idea to add a hover style to match the others, and it might be an idea to use cursor: pointer; too. Just to make it consistent with other buttons and links in the interface.
ETA: Try this for a basic HTML test page. So far I've only tested it in Pale Moon, but it should work in all browsers AFAIK.
ETA2: Better version. Should be clearer.
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Test page</title>
<style>
body {
background: #aaa;
}
#wrapper {
max-width: 800px;
margin: 4em auto;
text-align: center;
}
span {
position: relative;
padding: 0 6px;
border: 1px solid #444;
}
span:hover {
color: blue;
border: 1px solid blue;
}
input {
position: absolute;
left: 0;
width: 100%;
overflow: hidden;
color: white;
border: 1px solid red;
cursor: pointer;
}
.invisible {
opacity: 0;
}
</style>
</head>
<body>
<div id="wrapper">
<h1>
Testing nifty trix
</h1>
<h2>
Long text testing, everything visible
</h2>
Add files by dragging & dropping or
<span>
selecting them by clicking here, mate!
<input type="file">
</span>
<hr/>
<h2>
Long text testing, input hidden
</h2>
Add files by dragging & dropping or
<span>
selecting them by clicking here, mate!
<input class="invisible" type="file">
</span>
<hr/>
<h2>
Short text testing, everything visible
</h2>
Add files by dragging & dropping or
<span>
click here
<input type="file">
</span>
<hr/>
<h2>
Long text testing, input hidden
</h2>
Add files by dragging & dropping or
<span>
click here
<input class="invisible" type="file">
</span>
<hr/>
</div>
</body>
</html>
@Spuds i did that and unfortunately nothing was changed as the drop down menu still stuck at one option, only current page and still getting warning on line 67
Posting this reply from my iPhone and here are a shoot
(Link-4595) Edited by me to add another shoot for this page by Samsung/android device for comparison
(Link-4597)
@Antechinus ,I just translated into Arabic and switched wrapper direction to RTL , trying to create same environment as it would be.
please check again
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>صفحة اختبار</title>
<style>
body {
background: #aaa;
}
#wrapper {
max-width: 800px;
margin: 4em auto;
text-align: center;
direction: rtl;
}
span {
position: relative;
padding: 0 6px;
border: 1px solid #444;
}
span:hover {
color: blue;
border: 1px solid blue;
}
input {
position: absolute;
left: 0;
width: 100%;
overflow: hidden;
color: white;
border: 1px solid red;
cursor: pointer;
}
.invisible {
opacity: 0;
}
</style>
</head>
<body>
<div id="wrapper">
<h1>
Testing nifty trix - translated<br>wrapper direction set to rtl<br>
اختبار نيفتي تريكس
</h1>
<h2>
اختبار نص طويل ، كل شيئ ظاهر
</h2>
اضف ملف هنا بالسحب & الافلات أو
<span>
اختار ملف للرفع بالنقر هنا, اصاحبي!
<input type="file">
</span>
<hr/>
<h2>
اختبار نص طويل, الادخال مخفي
</h2>
اضف ملف هنا بالسحب & الافلات أو
<span>
اختار ملف للرفع بالنقر هنا, اصاحبي!
<input class="invisible" type="file">
</span>
<hr/>
<h2>
اختبار نص قصير ، كل شيئ ظاهر
</h2>
اضف ملف هنا بالسحب & الافلات أو
<span>
انقر هنا
<input type="file">
</span>
<hr/>
<h2>
اختبار نص طويل, الادخال مخفي
</h2>
اضف ملف هنا بالسحب & الافلات أو
<span>
انقر هنا
<input class="invisible" type="file">
</span>
<hr/>
</div>
</body>
</html>
Be sure to clear your browser cache on your iphone or it may not pick up the changes you made.
Ok, I checked it. Fine in Pale Moon.
ETA: Just installed Slimjet. Both pages are fine in that too, so should be good to go in Chrome or Opera as well. Can't imagine that Edge would have problems with something this basic either, although I'm still on W7 so can't check it.
Yes I already did that twice before checking so I can assure you that issue still exists and I noticed that its only 1 warning now as the other 2 disappeared
Not sure why you'd need to offset anything that far on a screen that is 30em max. :P
Question: why does Elk have the jump to? I remember there being some discussion about this ages ago. A lot of people never use the thing anyway. I have ever used it, either in SMF or Elk. It seems to be another one of those items that exists primarily to complicate development and clutter the interface. Oh, and bloat the javascript.
/me remembers he should add hidey code to his userContent.css :D
Adding the top/bottom button back should be easy. The tricky bit is arguing for days about who wants it, who doesn't, where it should go (everyone will disagree on this too) and what colour it should be.
Ditto admin button. But some admin pages are a pain on tiny screens. Others work quite well, or did last time I looked.
Please attach your modified script.js so I can check it ... I also noticed some really old crud in the JS that sets that box .... like some old ie only checks from like prehistoric days.
Yup
here it is
Looks fine ... attached is a version where I removed some old checks in the event it was messing up with iOS.
I don't get any errors in my console interacting with the jump control, at least on desktop or android devices. I don't have any iOS devices to test with.
You mean the good old days? :P
LOL .. yes like IE 5.5 and the like :P
I downloaded the attached file , cleared safari browser cache , loaded a post , touched the jump-to menu , but the result still the same
I downloaded chrome from apple store , repeated the process , still getting same result.
Let me explain what happens exactly , when i touch the jump-to menu , and as you can see in the previous attached shoot , the grey iOS scroll menu appears at bottom as usual , but with only one option which is non selectable , which is the current page.
Also when the jump-to menu get activated , it extend to a little bit larger size , but the theme get broken at the top where the mobile buttons appear , those buttons get shifted to the right and never get back to original location even after closing the jump-to menu, until i double touch somewhere , twice to get the normal look back.
Now , if touched the jump-to menu again , it will work normally showing all forums and allow choosing any of them, the top mobile buttons get shifted to the right and break the theme, but the menu functions normally .
thanks for bearing with me on this :-[
So why not just kill it, and save a lot of drama?
Maybe you don't use it , maybe it looks useless to you , I even read once that it causes a lot of queries and sql server load , I perfectly understand what you saying , I always disabled it in my forum in the past , but suddenly found that over 50% of my forum visitors are using mobile , so i have to put myself in their place , doing that i find it very difficult to navigate the forum on mobile without a jump-to menu , while on mobile , this menu increases the visits time on site, and that is something very important for site owners or admins . so if you guys provided some effective alternative , that would be great .
@Spuds for the record ,i just tested on another iOS device , iPhone 6 , and the result was the same , jump-to menu has the same issue as described before .
But it will only jump you to a board anyway, and you can access all of those from the board index. So it's only one more click without the jump to, and the linktree is in the same area of the page anyway. I have tried using the jump to, even when testing mobile resolutions, but personally I always find it easier to just go to the board index.
I will not argue with you about this , I just want to explain that on a narrow screen like my iPhone 5s with 320px width And with a forum consists of 29 parent boards and 32 child boards displayed as vertical listing as in my forum , the index page gets so tall and needs lot of scrolling up and down
So going to index page in my case is a bad idea :D
(Link-4601)
This just means "you should use proper ajax and not a fake", but it has almost likely nothing to do with the issue (because it works on android and desktops).
Recap: the jump to shows only the current board in any browser under iOS.
Does that sound right?
Good.
Let's see where exactly the problem is.
Change in script.js the function:
function grabJumpToContent(elem)
{
var oXMLDoc = getXMLDocument(elk_prepareScriptUrl(elk_scripturl) + 'action=xmlhttp;sa=jumpto;xml'),
aBoardsAndCategories = [],
i = 0,
n = 0;
if (oXMLDoc.responseXML)
{
var items = oXMLDoc.responseXML.getElementsByTagName('elk')[0].getElementsByTagName('item');
for (i = 0, n = items.length; i < n; i++)
{
aBoardsAndCategories[aBoardsAndCategories.length] = {
id: parseInt(items[i].getAttribute('id')),
isCategory: items[i].getAttribute('type') === 'category',
name: items[i].firstChild.nodeValue.removeEntities(),
is_current: false,
childLevel: parseInt(items[i].getAttribute('childlevel'))
};
}
}
for (i = 0, n = aJumpTo.length; i < n; i++)
aJumpTo[i].fillSelect(aBoardsAndCategories);
// Internet Explorer needs this to keep the box dropped down.
elem.style.width = 'auto';
elem.focus();
}
to:
function grabJumpToContent(elem)
{
alert('click');
var oXMLDoc = getXMLDocument(elk_prepareScriptUrl(elk_scripturl) + 'action=xmlhttp;sa=jumpto;xml'),
aBoardsAndCategories = [],
i = 0,
n = 0;
if (oXMLDoc.responseXML)
{
alert('response');
var items = oXMLDoc.responseXML.getElementsByTagName('elk')[0].getElementsByTagName('item');
for (i = 0, n = items.length; i < n; i++)
{
aBoardsAndCategories[aBoardsAndCategories.length] = {
id: parseInt(items[i].getAttribute('id')),
isCategory: items[i].getAttribute('type') === 'category',
name: items[i].firstChild.nodeValue.removeEntities(),
is_current: false,
childLevel: parseInt(items[i].getAttribute('childlevel'))
};
}
alert(aBoardsAndCategories.length);
}
for (i = 0, n = aJumpTo.length; i < n; i++)
aJumpTo[i].fillSelect(aBoardsAndCategories);
// Internet Explorer needs this to keep the box dropped down.
elem.style.width = 'auto';
elem.focus();
}
to see if the function is actually called, if the response is valid XML and how many elements are found to be added.
The new function generates some message boxes any time you click the jump to, so you may want to keep it live only for the time to give it a try. ;)
@emanuele , here is the test result
when touch > screen zoom in + menu size extend + page shifted > msg box1 :click
when close box1 > menu open with one option only > msg box2 :response
when close box2 > box3 : 71
when close box3 > page zoom out back to normal + menu closed, and operational now
So, the click is executed and the list is populated.
But it is now updated when displayed.
hmm...
Just to be sure, could you change:
JumpTo.prototype.fillSelect = function (aBoardsAndCategories)
{
this.removeAll();
to:
JumpTo.prototype.fillSelect = function (aBoardsAndCategories)
{
this.removeAll();
alert('yes');
always in the same file.
I was to be sure the things are added.
Now when close msg box3 which displaying 71 , I get a new msg box displaying : yes
Good... well, not exactly.
Can't think right, now, tomorrow... :(
As another "experiment" on this issue.
I'd like to move the population of the select box from the onfocus event to an onload event. I'm thinking that manipulating the select box post page load is just making iOS behave poorly.
So do to this, use this version of script.js and then edit MessageIndex.template.php as follows.
sGoButtonLabel: "', $txt['quick_mod_go'], '"
});
sGoButtonLabel: "', $txt['quick_mod_go'], '"
});
grabJumpToContent();
so just adding that grabJumpToContent(); call after line 368 ... then lets see how iOS responds to that.
eta: removed async version of script to avoid confusion
The issue seems to be similar to these ones:
http://stackoverflow.com/questions/15283064/adding-options-to-a-select-element-dynamically-just-before-the-user-opens-it
https://rothmanshore.com/2011/08/08/html-shortcut-dynamically-populate-a-select-list-drop-down-when-it-is-first-clicked/
unrelated, but since I found it, this seems nice:
https://github.com/HemantNegi/jquery.sumoselect
Interesting reading.
If we feel that the first event is being canceled in iOS (like IE 8/9), then adding a second event after the onfocus (used to populate) , lets try that instead.
@Spuds OK this experiment fixed the issue !!
Cool ... Looks like we found the issue. I tried the second event as suggested in the above links but was not able to get that to work in ie8 or ie9 (yes I have old test beds just for that, and yes it caused me great trauma).
@emanuele what, if anything, do we want to do about this for 1.0.10 ??
I'm just curious about what is the outcome of another little test.
@sherif could you add this line:
alert(('implementation' in document ? 'implementation' : 'onmouseover') + ('onbeforeactivate' in document ? 'onbeforeactivate' : 'onfocus'));
for example after:
JumpTo.prototype.showSelect = function ()
{
var sChildLevelPrefix = '';
and report what the message box says with you click on the jump to?
Be sure to put back the original script.js as well !!!!!
@emanuele I get this alert but before the page load , before touching anything
implementationonfocus
@Spuds do you mean remove this last testing code or something else ? ::)
using the last js file from
@Spuds , modifying as
@emanuele test , i get the same mentioned response
I get this alert but before (or while) the page loads , before touching anything
implementationonfocus
then by touching the menu , it works normally !!
Okay, then if you have time, one last try: remove all the changes suggested up until now, including the one from Spuds a few posts above, and in script.js change:
('implementation' in document ? '' : 'onmouseover="grabJumpToContent(this);" ')to:
'onmouseover="grabJumpToContent(this);" '
or alternatively, pick a topic at: http://www.elkarte.it/community/index.php (it's another domain, not here ;)) and see if it works.
I am using now the last js file uploaded by
@Spuds , its the original without any changes but yours.
I just removed your latest test alert, its the only change in this file , and applied your last modification .
The menu works now ,
it just takes more time now to open after I touch it , like 4 seconds delay , i tried another healthy internet connection, but the delay still there.
I clear cache every time before testing , I am not sure about the delay , it happens once then not the other , and so on
Testing on this domain worked good , no delay
Actually, I forgot we were talking about mobile, so the mouseover may not alwys work... maybe touchstart?
Opened the issue so it gets addressed in 1.0.10 (no eta, it will be ready when its ready :P )
Going this route a few more things.
1) As the event is now moving earlier in the stack, is the onfocus event needed anymore? Its not needed for any desktop browsers that I can see.
2) The onbeforeactivate should be removed and just use onfocus IF that is even required anywhere. There is zero need to support an IE only event. I'm thinking remove both onfocus and onbeforeactivate.
3) The onmouseover event needs to be cleared once it has been fired or the select box will get jumbled up on a second hover. This is done in the fillSelect function.
4) The grabJumpToContent should be updated to not be blocking, that was in done one of my experiments as simple callback.
Looks like there is browsers mapping support for that event on a touch device, but still .... Since we have the is_touch flag in the JS anyway we could check that and set either the touchstart or onmouseover so its prim and proper, and then remove the correct event once its fired.
(is_touch ? 'touchstart' : 'onmouseover') + '="grabJumpToContent(this);"' +
Would like an iOS test with the onfocus events removed.
In the mean time I have a vb forum about to be replaced with this elkarte setup I am using for tests , so i guess i will revert back to last working js version by
@Spuds fix, since it will act normal for mobile users , unless you have another advice for me .
If you need more iOS tests I still can help !!
Sounds like a (good) plan! :D
Then for the next experiment !!
Use this version of script.js and do not make any edits to messageindex.template. php, leave it just like the default.
This version one uses the single event, as well as the official touch event if its on a touch enable device mobile device. Lets see how iOS likes that.
Messed up behaviour , only one option and furthermore,
closing menu then opening again doesn't load the rest of the options
I'm was not sure that touchstart was able to be used in the way I implemented it, I think I have my answer!
I've now done a proper addEventListener for the event. I've tested this on windows, mac and android and it works fine. Now the question is does this work on iOS (with the single event). Attached for testing.
This one worked normally , everything looks good
Thats great to hear! Thanks for doing all that testing :D Now the question is do we want to slide this in to 1.0.10 ?
@emanuele what do you think?
Well, we have already so many things... :P
One more nobody will notice. O:-)
May I ask you to kindly update script.js for this forum asap , I just happen to use my iPhone a lot following topics here
Better have it on the repo, otherwise next time I do a site update, all the changes will be gone. :)