[regression] bug 737307 breaks administrator Toolbar buttons on joomla websites

RESOLVED WORKSFORME

Status

()

Core
Document Navigation
--
major
RESOLVED WORKSFORME
6 years ago
6 years ago

People

(Reporter: Jesper Hansen, Unassigned)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(firefox12-, firefox13-, firefox14-, firefox-esr10-)

Details

(URL)

(Reporter)

Description

6 years ago
With the help of edmorley#developers (thanks!) was I able to hunt down a bug in the administrator panel of a joomla installation. 

It seems to be caused by changeset http://hg.mozilla.org/integration/mozilla-inbound/rev/6a2c57fa8edf

To reproduce:
1. Visit the URL and login using demo/demo
2. Click one of the joomla toolbar buttons (new,edit,publish...)

Result:
1. # is appended to the URL 
2. In the webconsole: 
[15:44:23.735] POST http://demo17.cloudaccess.net/administrator/index.php?option=com_content&view=articles [HTTP/1.1 undefined 0ms]
3. (Connection is killed?)

Expected result:
1. In the web console:
[16:02:47.572] POST http://demo17.cloudaccess.net/administrator/index.php?option=com_content&view=articles [HTTP/1.1 303 See other 292ms]
[16:02:47.859] GET http://demo17.cloudaccess.net/administrator/index.php?option=com_content&view=article&layout=edit [HTTP/1.1 200 OK 1237ms]

Regression impact: Every joomla installation out there :(

Can't add 737307 as blocking myself (Access denied). Maybe that is something to look into as well.
(Reporter)

Comment 1

6 years ago
I remembered the result wrong. It is written as:
[16:08:36.587] POST http://demo17.cloudaccess.net/administrator/index.php?option=com_content&view=articles [undefined 1ms]

Updated

6 years ago
Blocks: 737307

Updated

6 years ago
tracking-firefox-esr10: --- → ?
tracking-firefox12: --- → ?
tracking-firefox13: --- → ?
tracking-firefox14: --- → ?
(Reporter)

Comment 2

6 years ago
A smaller testcase http://bug739588.staunhansen.dk/testy.php

The only thing done in this php file is:
if ( ! empty( $_POST ) ) {
	$fn = $_REQUEST['fname'];
	$ln = $_REQUEST['lname'];

	header("HTTP/1.1 303 See Other");
	header("Location: /testy2.php?fn=".$fn."&ln=".$ln);
}
So to be clear about what's happening, the fix for bug 737307 changes so our behavior so that if you:

 * navigate to foo.html, then immediately
 * navigate to #,

we cancel the foo.html load.  I bet joomla is doing something like this, perhaps with a link href="#".

We're going to have to change the fix for bug 737307 to something less disruptive.

Comment 4

6 years ago
Is this still occurring on the latest nightlies?
(Reporter)

Comment 5

6 years ago
Has something been pulled out from bug 737307? 
I am still on 14.0a1 (2012-03-21) since I am working with a joomla system atm.

Comment 6

6 years ago
The original fix for bug 737307 has been backed out - and a different approach landed, which will end up in tomorrow's (2012-03-31) Nightly once inbound merges.

Once that Nightly is available, please can you confirm whether the issue exists with this revised approach - thanks :-)
(Reporter)

Comment 7

6 years ago
Alright. Will give it a go tomorrow. 
bug 737307 is a security bug and I can therefor not see if it has been pulled out in the bug report without having to stare at commit logs otherwise (again :))

Comment 8

6 years ago
Please re-nominate if this continues to be a problem in the latest nightlies.
tracking-firefox-esr10: ? → -
tracking-firefox12: ? → -
tracking-firefox13: ? → -
tracking-firefox14: ? → -
(Reporter)

Comment 9

6 years ago
Fixed in latest nightly as of 2012-03-31 and it once again works and submits as intended.
I assume it was fixed in bug 737307
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Great - thanks for confirming Jesper! :-)
You need to log in before you can comment on or make changes to this bug.