Status

task
RESOLVED FIXED
7 years ago
2 months ago

People

(Reporter: davidben, Assigned: bburton)

Tracking

Details

(Whiteboard: [mediawiki-bugzilla])

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.33 Safari/535.19

Steps to reproduce:

Visit https://wiki.mozilla.org/


Actual results:

In Chrome's beta channel release, there are scripts and stylesheets that are blocked. The offending URLs are

http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.14/themes/base/jquery-ui.css
http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.14/themes/smoothness/jquery-ui.css
http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js
http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.14/jquery-ui.min.js


Expected results:

Those resources should be fetched over HTTPS.
Indeed, over to IT. Not sure why we're including external stylesheets in the first place. We should host those locally.
Assignee: nobody → server-ops-devservices
Status: UNCONFIRMED → NEW
Component: Other → Server Operations: Developer Services
Ever confirmed: true
Product: Websites → mozilla.org
QA Contact: other → shyam
Version: unspecified → other
Assignee: server-ops-devservices → server-ops
Component: Server Operations: Developer Services → Server Operations: Web Operations
QA Contact: shyam → cshields
This is caused by the recent addition of the Mediawiki-Bugzilla extension. Assigning to the maintainer of this extension...

Brandon, can you make these protocol-relative, and/or locally included in your git repo? Let me know when one or the other is done (and what the repo is again, so I can re-clone) and I can push out the fix.

I have a mild preference to locally-hosting these files as well, simply to remove a dependency on a 3rd-party service. For what its worth, Semantic MediaWiki and Semantic Forms both locally-host some jquery files as well, so there's some precedence within wikimo for doing it this way.
Assignee: server-ops → bsavage
Duplicate of this bug: 729637
For the record, this is a much bigger problem on non Firefox browsers. On Firefox, people turn off the warning and never see it. On chrome, you get the message on every page.

A quick fix would be just to make those two links relative. Google provides https versions of the files.
This is really annoying and is a quite easy fix. Is there a reason it's not being fixed?
Because it was assigned to me while I was asleep last night and I've been in meetings all day. Patches encouraged: https://github.com/mozilla/mediawiki-bugzilla I'll be on vacation until Wednesday.
Sleep is for the weak! :)

I'll take a look.
I have a fix ready. Just need to ensure that my copy of the repo is in sync with the above and issue the pull request. My fix bundles the jquery and jquery ui packages in the mediawiki-buzilla package so that everything is local. Here's my copy:

https://github.com/lmandel/mediawiki-bugzilla
My copy was woefully out of date. Now that it's back in sync I have issued a pull request for Brandon to review and grab the changes.
This has been merged to master.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
This patch is no good... It results in the page requesting things like this:

https://wiki.allizom.org/$wgScriptPath/extensions/Bugzilla/web/jqueryui/1.8.14/jquery-ui.min.js

$wgScriptPath is being passed directly, not interpreted.


Compare:

Bugzilla.php:    $out->addScript('<script type="text/javascript" src="$wgScriptPath/extensions/Bugzilla/web/jqueryui/1.8.14/jquery-ui.min.js"></script>');

vs. this line found elsewhere in the same file:

Bugzilla.php:    $out->addScriptFile("$wgScriptPath/extensions/Bugzilla/web/js/jquery.dataTables.js" );


The latter works properly... the former results in a literal copy of the string into the HTML.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Interesting that this worked on my test system. I have made the changes as you suggested above. Testing shows that all is functional. I have initiated a pull request to the mozilla repo.
Assignee: bsavage → network-operations
Component: Server Operations: Web Operations → Server Operations: Netops
QA Contact: cshields → ravi
Whiteboard: [mediawiki-bugzilla]

Comment 13

7 years ago
I'm not sure what netops can do to help here...  Assigning back to original owner unless there's an action item for us.
Assignee: network-operations → server-ops
Component: Server Operations: Netops → Server Operations: Web Operations
QA Contact: ravi → cshields
(Assignee)

Updated

7 years ago
Assignee: server-ops → bburton
(Assignee)

Comment 14

7 years ago
If the pull request mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=729605#c12 has been merged into master, I can work with :jakem to push this to stage and make sure it's working. 

Let us know, feel free to ping me on irc too
Yup. The request has been merged into master along with fixes for two other bugs. See bug 733389 for a deployment request for the three fixes.
The fix is pushed live... this seems resolved.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations

Updated

2 months ago
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.