Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
3811
Archived fixes / Re: Input boxes not working in Chrome
« on January 25th, 2013, 03:02 PM »
Hmmm... Very very odd.
Open quick reply, no can write, click the arrow, can write (contenteditable = good.)
Click the arrow (to textarea), can keep writing *apparently*. I'm saying 'apparently' because it doesn't actually restore the textarea (the outline color not changing in Chrome is a hint... And it's buggy everywhere at this point, like clicking smileys won't add them, etc.)
Click the arrow (to div), the text is replaced by whatever was in the div before I made the 'wrong' click... EH??!?!!*#$!!!
First time this ever happens to me... Dunno if it's related to the bug above, probably is.
It's quite f'ed up if I must say...
Open quick reply, no can write, click the arrow, can write (contenteditable = good.)
Click the arrow (to textarea), can keep writing *apparently*. I'm saying 'apparently' because it doesn't actually restore the textarea (the outline color not changing in Chrome is a hint... And it's buggy everywhere at this point, like clicking smileys won't add them, etc.)
Click the arrow (to div), the text is replaced by whatever was in the div before I made the 'wrong' click... EH??!?!!*#$!!!
First time this ever happens to me... Dunno if it's related to the bug above, probably is.
It's quite f'ed up if I must say...
3812
Bug reports / Re: Weaving & Warm issues in iOS
« on January 25th, 2013, 12:05 PM »
Well.. Here's what's happening:
- Before, a long time ago, I'm guessing that the browser name was recorded as 'tablet' for iPads. I'm not 100% sure about that... But it's the only logical explanation to it failing now.
- Because now they're recorded as ios, it means they're sharing the same file as iPhones, with a larger font to accomodate for their ridiculous screen size. iPads are 'regular' tools for browsing, so they don't need the extra stuff. I should remove the 'ios' code for it. And/or restore the iphone/tablet difference I had before.
My main problem is that I don't have an iPad at all... :^^;: Hard to test in these conditions!
- Before, a long time ago, I'm guessing that the browser name was recorded as 'tablet' for iPads. I'm not 100% sure about that... But it's the only logical explanation to it failing now.
- Because now they're recorded as ios, it means they're sharing the same file as iPhones, with a larger font to accomodate for their ridiculous screen size. iPads are 'regular' tools for browsing, so they don't need the extra stuff. I should remove the 'ios' code for it. And/or restore the iphone/tablet difference I had before.
My main problem is that I don't have an iPad at all... :^^;: Hard to test in these conditions!
3813
Archived fixes / Re: Plugin execution
« on January 25th, 2013, 12:01 PM »
Anyone else..?
:edit: Had rev number on reading this page. Quick replied. Page refreshed with my post, and with no rev in it. Can you check what it does after posting..?
:edit: Did another quick reply, Wedge didn't hide it this time though.
:edit: It hid it after I pressed Merge Posts :P
Posted: January 25th, 2013, 12:01 PM
:edit: Had rev number on reading this page. Quick replied. Page refreshed with my post, and with no rev in it. Can you check what it does after posting..?
:edit: Did another quick reply, Wedge didn't hide it this time though.
:edit: It hid it after I pressed Merge Posts :P
3814
Bug reports / Re: Minor bug with drafts and entities
« on January 25th, 2013, 11:59 AM »
- weSaveEntities() is doing its work, but APPARENTLY it isn't called in quick reply... Maybe that's here...? But I seem to remember the bug happened in quick edit mode, too... Test é > < – é<>... :edit: Yep, they're not converted... Another test -- quick edit -- > < :edit: Okay, looks like it's in quick reply only.
- I have 14 drafts, 6 of which are completely empty. That's a bug. Has to be... Others MIGHT be due to chance. But the empty drafts... I thought Wedge ensured these didn't get saved?
- I have 14 drafts, 6 of which are completely empty. That's a bug. Has to be... Others MIGHT be due to chance. But the empty drafts... I thought Wedge ensured these didn't get saved?
3815
Archived fixes / Re: Plugin execution
« on January 25th, 2013, 11:51 AM »
Just reproduced on refresh #3 of this very page. Using Safari 5.1 on regular Display page (not Post page.)
And again after posting this... Three refreshes in a row! Refresh #4 had the rev number, and refresh #5 didn't.
I'll just stop here, I won't spend the day reloading :P
And again after posting this... Three refreshes in a row! Refresh #4 had the rev number, and refresh #5 didn't.
I'll just stop here, I won't spend the day reloading :P
3816
Bug reports / Header headache
« on January 25th, 2013, 11:18 AM »
Not really a Wedge bug report per se.
See, a small portion of Wedge user agents aren't using gzipping.
I decided to try and see what was causing that.
First of all, I added this simple line of code:
Code: [Select]
This allows me to look into server headers within the error log. Sorry Pete, that's the reason why it's crowded with these :P
* It appears that:
- Many are due to robots, such as 'UptimeRobot', not declaring gzip capability, which isn't a problem because bots don't need CSS files. So, first thing: should I add an exception in JS/CSS loading for we::$browser['probably_robot']...? If yes, should we add more bots to the spider log? Or, more realistically, either add those we found in the current error log, or add a generic stripos(we::$ua, 'bot') and enforce gzipping *within* CSS and JS only, for these?
Also, bots usually don't provide a 'fake' browser, so they end up with no browser name internally, which means they all use the same, browser-less, uncompressed file. Which isn't a big deal I guess...
- I'd read posts about Accept-Encoding being mangled by proxies and antiviruses (e.g. http://calendar.perfplanet.com/2010/pushing-beyond-gzipping/) which also provides some solutions, but this doesn't seem to be the case here. Not finding anything special. Perhaps this practice is no longer a reality. Or perhaps they just strip the header entirely... There are solutions for this, but they imply JavaScript-testing, and at that point the first uncompressed file is already generated so we'd have to: generate CSS file, test whether gzip is available, if no do nothing, if yes delete generated CSS file and use (or generate) gzipped version... Seems a lot for not much.
- I was hoping to use that to help reduce the number of rogue files, considering that adding the OS version would potentially multiply the number of files by a great magnitude. However, in just one hour online here, not many files were created, so it probably isn't a big deal.
I'm curious to know if there's anything of interest here.
* Also, there is something I'd like for us to deal with... And possibly more important.
CSS files are being generated even when an Atom feed is being requested. I don't think that's the intended way...! I looked into the code, and it seems that most of the bypasses are done through isset($_REQUEST['xml']), which is a bit limited. First of all, there's always the cool Ajax flag that we should test against when loading from jQuery stuff. Then, the feeds --- they generate XML files. Why don't they go through the exceptions...?
See, a small portion of Wedge user agents aren't using gzipping.
I decided to try and see what was causing that.
First of all, I added this simple line of code:
if (!$can_gzip) log_error(print_r($_SERVER, true));This allows me to look into server headers within the error log. Sorry Pete, that's the reason why it's crowded with these :P
* It appears that:
- Many are due to robots, such as 'UptimeRobot', not declaring gzip capability, which isn't a problem because bots don't need CSS files. So, first thing: should I add an exception in JS/CSS loading for we::$browser['probably_robot']...? If yes, should we add more bots to the spider log? Or, more realistically, either add those we found in the current error log, or add a generic stripos(we::$ua, 'bot') and enforce gzipping *within* CSS and JS only, for these?
Also, bots usually don't provide a 'fake' browser, so they end up with no browser name internally, which means they all use the same, browser-less, uncompressed file. Which isn't a big deal I guess...
- I'd read posts about Accept-Encoding being mangled by proxies and antiviruses (e.g. http://calendar.perfplanet.com/2010/pushing-beyond-gzipping/) which also provides some solutions, but this doesn't seem to be the case here. Not finding anything special. Perhaps this practice is no longer a reality. Or perhaps they just strip the header entirely... There are solutions for this, but they imply JavaScript-testing, and at that point the first uncompressed file is already generated so we'd have to: generate CSS file, test whether gzip is available, if no do nothing, if yes delete generated CSS file and use (or generate) gzipped version... Seems a lot for not much.
- I was hoping to use that to help reduce the number of rogue files, considering that adding the OS version would potentially multiply the number of files by a great magnitude. However, in just one hour online here, not many files were created, so it probably isn't a big deal.
I'm curious to know if there's anything of interest here.
* Also, there is something I'd like for us to deal with... And possibly more important.
CSS files are being generated even when an Atom feed is being requested. I don't think that's the intended way...! I looked into the code, and it seems that most of the bypasses are done through isset($_REQUEST['xml']), which is a bit limited. First of all, there's always the cool Ajax flag that we should test against when loading from jQuery stuff. Then, the feeds --- they generate XML files. Why don't they go through the exceptions...?
3817
Bug reports / Re: Weaving & Warm issues in iOS
« on January 25th, 2013, 11:04 AM »
So at this point the site is up to date and works fine in Safari for Windows...
I just launched it on my iPod (iOS 5.1 - Chrome 23), at the very least try it on your iPads and tell me the results, and whether or not you're using Safari Mobile (which version) or Chrome (which version). Since both rendering engines are the same, the results should be identical too, except if you're on iOS 5.1 and using that version of Chrome, which is where it could get interesting.
Hack away!
I just launched it on my iPod (iOS 5.1 - Chrome 23), at the very least try it on your iPads and tell me the results, and whether or not you're using Safari Mobile (which version) or Chrome (which version). Since both rendering engines are the same, the results should be identical too, except if you're on iOS 5.1 and using that version of Chrome, which is where it could get interesting.
Hack away!
3818
Bug reports / Re: Minor bug with drafts and entities
« on January 25th, 2013, 10:48 AM »
Bumping two bugs with one stone :P
- Entities: reminder, need to fix the fact that Wedge seems to turn & nbsp; into an actual space at post save time.
- Drafts: I thought this was fixed LONG ago, but I just went into my draft section (which I don't visit often, but I was trying to get my earlier bug report which I'd deleted but Safari kindly prevented me from Ctrl-Z'ing it back into life...) (and yes, the draft area didn't have it either...), and it had about 20 messages, most of which were either empty (I thought we didn't save empty drafts...?!), or with the exact same contents as an existing post (such as a New Revs post)... Which should have been deleted at the time it was posted...
So, I'm thinking... Bug still there...? :-/
- Entities: reminder, need to fix the fact that Wedge seems to turn & nbsp; into an actual space at post save time.
- Drafts: I thought this was fixed LONG ago, but I just went into my draft section (which I don't visit often, but I was trying to get my earlier bug report which I'd deleted but Safari kindly prevented me from Ctrl-Z'ing it back into life...) (and yes, the draft area didn't have it either...), and it had about 20 messages, most of which were either empty (I thought we didn't save empty drafts...?!), or with the exact same contents as an existing post (such as a New Revs post)... Which should have been deleted at the time it was posted...
So, I'm thinking... Bug still there...? :-/
3819
Archived fixes / Input boxes not working in Chrome
« on January 25th, 2013, 10:44 AM »
This happened to me twice -- yesterday, and this morning. Both times, it didn't happen at startup, only after a while.
Suddenly, in Chrome, all text inputs in Wedge would stop working. Cursor shows up, but typing doesn't add anything to them.
It only works in the Search Box. Removing (with the dev tools) the search class from it did at some point block input, restoring the class restored input, but this didn't 'fix' other text inputs. Also, removing the search class a second time didn't seem to break functionality again.
Just like the previous bug I reported -- it's very random. But if it's happened to me twice... And it can't be fixed by closing and reopening the tab, only by closing Chrome... I'm guessing I should report.
This is with version 26 (Chrome Canary).
Suddenly, in Chrome, all text inputs in Wedge would stop working. Cursor shows up, but typing doesn't add anything to them.
It only works in the Search Box. Removing (with the dev tools) the search class from it did at some point block input, restoring the class restored input, but this didn't 'fix' other text inputs. Also, removing the search class a second time didn't seem to break functionality again.
Just like the previous bug I reported -- it's very random. But if it's happened to me twice... And it can't be fixed by closing and reopening the tab, only by closing Chrome... I'm guessing I should report.
This is with version 26 (Chrome Canary).
3820
Archived fixes / Plugin execution
« on January 25th, 2013, 10:40 AM »
I noticed something odd... On some pages, sometimes, the 'rev 1873' mention in the footer just doesn't show up.
This is in any browser (I think), Warm (probably all other skins too). Last reproduced on the Post page (i.e. where I am right now), usually refreshing the page will fix it. At one point I refreshed again and it disappeared again (after being there the last time). All subsequent (20+) refreshes had the rev number.
So I'd say this is very, very random, but if the plugin executing on every page is critical, it might be a show-stopper...
Sorry I can't help more. Just try it a couple of minutes and tell me if you can reproduce!
This is in any browser (I think), Warm (probably all other skins too). Last reproduced on the Post page (i.e. where I am right now), usually refreshing the page will fix it. At one point I refreshed again and it disappeared again (after being there the last time). All subsequent (20+) refreshes had the rev number.
So I'd say this is very, very random, but if the plugin executing on every page is critical, it might be a show-stopper...
Sorry I can't help more. Just try it a couple of minutes and tell me if you can reproduce!
3821
Archived fixes / Re: Viewing an unread media item does not mark it as read
« on January 24th, 2013, 11:19 PM »
The lack of floating topics in Wedge may very well end up being my biggest regret.
Heck even Drupal is based entirely on that...
Heck even Drupal is based entirely on that...
3822
Archived fixes / Re: Viewing an unread media item does not mark it as read
« on January 24th, 2013, 11:11 PM »
Not surprised. Last time I checked it, a year ago at least, people acted like it was part of SMF and thus the team knew everything about it.
Mehh.
Still. I pretty much abandoned aeme even in Wedge and that's a shame. I so wanted it to be the first stone in my building: having any type of content available as floating topics.
Sob.
Mehh.
Still. I pretty much abandoned aeme even in Wedge and that's a shame. I so wanted it to be the first stone in my building: having any type of content available as floating topics.
Sob.
3823
Archived fixes / Re: Viewing an unread media item does not mark it as read
« on January 24th, 2013, 11:06 PM »
Fixed!
I'd love to know how this bug came into being. None of the other log_media queries had it...
I'd love to know how this bug came into being. None of the other log_media queries had it...
3824
Features / Re: New revs
« on January 24th, 2013, 10:57 PM »
rev 1872 - the Aeva Media fix commit. Keep 'em coming!
(3 files, 3kb)
! Fixed that annoying little bugger of a bug that prevented documents (including compressed files) from being marked as read just by visiting their item page in the Media gallery. I'm afraid this bug is also in Aeva Media for SMF (all versions), and I promised myself never to update it, so it's a bit of a... bugger, again. Well, I guess I'll have to do it at some point. I'm starting to wonder if people are aware that I don't read the AeMe topic at sm.org and that if they want to report bugs, they should do it on wedge.org...?! (Subs-Media.php)
! Marking the last Unseen Media page as seen would redirect you to an empty page, instead of the last available page of unseen items. (Aeva-Gallery2.php)
* I don't like h4 being bold either. I probably should unbold all header tags while I'm at it... (Warm/extra.css)
(3 files, 3kb)
! Fixed that annoying little bugger of a bug that prevented documents (including compressed files) from being marked as read just by visiting their item page in the Media gallery. I'm afraid this bug is also in Aeva Media for SMF (all versions), and I promised myself never to update it, so it's a bit of a... bugger, again. Well, I guess I'll have to do it at some point. I'm starting to wonder if people are aware that I don't read the AeMe topic at sm.org and that if they want to report bugs, they should do it on wedge.org...?! (Subs-Media.php)
! Marking the last Unseen Media page as seen would redirect you to an empty page, instead of the last available page of unseen items. (Aeva-Gallery2.php)
* I don't like h4 being bold either. I probably should unbold all header tags while I'm at it... (Warm/extra.css)
3825
Features / Re: New revs
« on January 24th, 2013, 06:12 PM »
rev 1871
(7 files, 5kb)
! Wedge wasn't recording the OS name and version in CSS filenames, contrary to what it was supposed to do. This caused some issues, notably Safari for Windows stylesheets being shared with iPhone stylesheets... Not a good idea! (Subs-Cache.php)
! Fixed inconsistent padding around linktree elements. This was due to a classic: whitespace between them... Reminds me that it's best to remove whitespace when possible. It saves bytes in the end, and avoids silly issues like this one. Well, at least when an element is likely to have its display type changed to block or inline-block or inline depending on the skin... (index.template.php, Warm/extra.css)
! Various fixes for Warm, mostly due to Open Sans Bold not looking really good. It's best to just focus on using Open Sans in its regular weight... (Warm/extra.css)
- Removing Optima from fallback fonts -- it looks ugly in iOS. Also removing PT Sans from all stylesheets: I should tell you that I'd installed the font manually on my PC and I can't expect people to be happy with a design I'm not seeing (i.e. the fallback font I'm never seeing.) (common.css, Wine/common.css, Wine/extra.css)
* Home language file wasn't using UTF8. (Home.french.php)
(7 files, 5kb)
! Wedge wasn't recording the OS name and version in CSS filenames, contrary to what it was supposed to do. This caused some issues, notably Safari for Windows stylesheets being shared with iPhone stylesheets... Not a good idea! (Subs-Cache.php)
! Fixed inconsistent padding around linktree elements. This was due to a classic: whitespace between them... Reminds me that it's best to remove whitespace when possible. It saves bytes in the end, and avoids silly issues like this one. Well, at least when an element is likely to have its display type changed to block or inline-block or inline depending on the skin... (index.template.php, Warm/extra.css)
! Various fixes for Warm, mostly due to Open Sans Bold not looking really good. It's best to just focus on using Open Sans in its regular weight... (Warm/extra.css)
- Removing Optima from fallback fonts -- it looks ugly in iOS. Also removing PT Sans from all stylesheets: I should tell you that I'd installed the font manually on my PC and I can't expect people to be happy with a design I'm not seeing (i.e. the fallback font I'm never seeing.) (common.css, Wine/common.css, Wine/extra.css)
* Home language file wasn't using UTF8. (Home.french.php)