Last modified: 2014-02-12 23:54:53 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 T32985, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 30985 - Mobile header expanding and menu don't work until page loads
Mobile header expanding and menu don't work until page loads
Status: RESOLVED WONTFIX
Product: MobileFrontend
Classification: Unclassified
stable (Other open bugs)
unspecified
All All
: High normal
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-19 03:56 UTC by Yair Rand
Modified: 2014-02-12 23:54 UTC (History)
10 users (show)

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


Attachments
application.js (2.52 KB, text/plain)
2011-09-20 05:40 UTC, Yair Rand
Details
application.js (3.17 KB, text/plain)
2011-10-02 22:35 UTC, Yair Rand
Details
new js (5.73 KB, text/plain)
2011-10-27 14:39 UTC, Yair Rand
Details
newer js (6.20 KB, text/plain)
2011-10-30 15:38 UTC, Yair Rand
Details
+history suggestions (7.08 KB, text/plain)
2011-11-02 16:16 UTC, Yair Rand
Details

Description Yair Rand 2011-09-19 03:56:32 UTC
In the mobile view, clicking the logo in the top-left corner to display the Home/Random buttons and clicking headers to show/hide following sections don't work unless the onload event has fired. Functions should be attached to the headers and button using onclick="..." in the HTML instead of using javascript in the head.
Comment 1 Brion Vibber 2011-09-19 20:43:46 UTC
Probably should at least run on dom-ready / trigger from end of document rather than onload, which IIRC waits for images to load as well.
Comment 2 Brion Vibber 2011-09-19 20:47:41 UTC
Note another thing that can be done -- especially since it looks like most of the event handlers are fairly generic -- is to bind a bubbleable event handler on the document right smack at the start, and let that check things like 'oh is this an h2 with a section_heading class? let's do X'.

Then there's no need to go iterating through the document looking for individual items.

However that might need some more compat-checking. :P
Comment 3 Patrick Reilly 2011-09-19 20:58:48 UTC
Fixed in r97556.
Comment 4 Yair Rand 2011-09-20 05:40:42 UTC
Created attachment 9077 [details]
application.js

That's not really completely fixed. The revision changed it so that it doesn't need to wait for the images to load, but it still needs to wait for the rest of the document to load. It would probably be best to load the script in the head and attach an event handler to the document at the beginning per Brion. The part that needs to run after the DOM is loaded could be called with a <script>pageLoaded()</script> at the bottom of the body, and the logo button could have a onclick="logoClick()" so that it doesn't need to be part of the general document click event.
Comment 5 Yair Rand 2011-10-02 22:35:09 UTC
Created attachment 9146 [details]
application.js

(Script that also includes the more recently added features.)
Comment 6 Yair Rand 2011-10-25 13:31:03 UTC
Um, was I suppose to file a separate bug since this was marked as resolved?
Comment 7 Yair Rand 2011-10-27 14:39:48 UTC
Created attachment 9295 [details]
new js

(Hm, I get the feeling I'm doing something incorrectly...)

This bug still hasn't been fixed, and since it was filed there have been a whole bunch of changes to the js files, as well as an entirely new js file (sometimes?) added, and as I was looking at the new stuff I kept being annoyed at the lack of [edit] button, so I'm just going to attach a js file to this bug which also modifies a bunch of stuff unrelated to the original bug as well as using the original change. I hope that's not a problem.
Comment 8 Yair Rand 2011-10-30 15:38:00 UTC
Created attachment 9319 [details]
newer js

Hm, it looks like there have been more changes to the js since I attached the last one... Well, here we go again.

New js, includes a bunch of modifications. Summary: Clicking headers and links to hidden sections work before the page has loaded, clicking the logo to expand the menu works before the page has loaded, search box suggestions work before the page has loaded, suggestions xmlhttprequest has been changed to use json, lowering the amount of data requested by about 96% as well as simplifying the js significantly, replaced most usages of innerHTML with regular DOM methods, and a bunch of general cleanup. I also changed the format of the suggestions box a bit, which requires a bit of css changing. Unfortunately I can't figure out which file is the central css, and anyway there's a good chance it will be changed again before this is reviewed, so I'll just stick the added css here:
#results .suggestions-results a{
       display:block;
       margin: 0;
       line-height: 2.7em;
       padding: 0.01em 0.25em;
       text-decoration:none;
       color: black;
       border-top:1px #888888 solid;
}
.suggestions-results div{
       float:right;
       margin: 0;
       line-height: 1.8em;
       padding: 0.01em 0.25em;
       font-size: 1.3em;
}
.suggestions-results a:hover{
       background-color: #ACD1E9;
}
And styles for .sq-val-update are no longer needed.

(If there actually is a way to just submit changes without things being attached to a bug, I would really like to know about it.)

...
Comment 9 Yair Rand 2011-11-01 14:13:40 UTC
(Forgot to mention that it also makes the search suggestions clickable in the non-text part (bug received a complaint at [[Wikipedia:Mobile_Extension_Feedback#Search_suggestions_cannot_be_tapped]]), and fixes the reliance on window.event, which doesn't work on certain browsers.)
Comment 10 Yair Rand 2011-11-02 16:16:36 UTC
Created attachment 9347 [details]
+history suggestions

Same changes as above, plus fix for (my possibly incorrect interpretation of) Bug 31598 ("Auto-complete based on history too"). Search suggestions display previously searched pages in the list, above the retrieved suggestions. (I don't actually think this is a good idea, especially with the 20% increase in js size, but there was a bug open for it...)
Comment 11 Yair Rand 2011-11-02 20:34:45 UTC
Hm, now a couple of the issues fixed here have also been fixed in entirely separate revisions by preilly. And new revisions have been made, which probably will require some more changes to the attachment. And after a month and a half and way too many "edit conflicts", there's been no progress. 

This is just not an effective way of getting things done. When new editing of a page is not started from the most recent revision, loads of work gets wasted, and it doesn't look like continually reworking the script to accommodate more recent changes is actually going to be productive.

<Gives up on bug.>
Comment 12 Patrick Reilly 2011-11-02 21:46:56 UTC
Partial fix for logo expansion in r101709.
Comment 13 Jon 2012-04-10 14:56:38 UTC
Mm... I'm a bit confused by this bug.
Script tags should be loaded after content as the content is the most important thing here.

Currently all content is loaded first then the page is enhanced - sections are turned on and content hidden.  Search will work without javascript and will enhance to use full screen search / search suggestions.

We may want to make the navigation menu work without javascript so that this is accessible before javascript loading but apart from this I think the current code base is the way it should be (although work should be done to reduce the content size payload so it loads quicker and thus js is loaded quicker)

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


Navigation
Links