Opened 10 years ago
Closed 4 years ago
#11100 closed defect (fixed)
dojo.hash breaks when there's a base tag
| Reported by: | Rob Retchless | Owned by: | bill |
|---|---|---|---|
| Priority: | high | Milestone: | 1.11 |
| Component: | General | Version: | 1.5.0b2 |
| Keywords: | Cc: | [email protected]… | |
| Blocked By: | Blocking: |
Description
If there's a <base> tag on the page that points at a different server or path, calling dojo.hash("someHash") adds the hash to the value in the base tag and updates the URL, causing a page transition. Dojo.hash should fully qualify on set.
Attachments (3)
Change History (19)
comment:1 Changed 10 years ago by
| Milestone: | tbd → 1.5 |
|---|
comment:2 Changed 10 years ago by
| Owner: | changed from anonymous to Rob Retchless |
|---|
comment:4 Changed 10 years ago by
| Milestone: | 1.5 → 1.6 |
|---|
comment:5 Changed 9 years ago by
| Milestone: | 1.6 → future |
|---|
(sadly) punting seemingly abandoned ticket and meta tickets to future
Changed 9 years ago by
| Attachment: | basehref_ff.html added |
|---|
a sample page which shows the issue in Firefox (any other browser should react as expected)
comment:6 Changed 9 years ago by
This bug seems to only occur in Firefox (3.x). As stated above the the hash gets added to the value of <base href="..."> instead of being applied to the current location.href.
Means:
Having a page on yourdomain.com with a base tag set to google.com using dojo.hash('someHash') will result in
a redirect to google.com#someHash instead of yourdomain.com#someHash.
This is because doojo.hash utilizes location.href to apply the hash. Better use location.hash to accomplish this task.
ff_basehref.html is a sample page which shows the issue in Firefox (any other browser should react as expected) hash.js.patch is patchfile with the one affected line.
NOTE: _replace() has to be fixed as well because location.replace("#"+hash); would also redirect to the value given in base href.
comment:7 Changed 9 years ago by
comment:8 Changed 9 years ago by
The patch looks good. My only concern is potential changes in encoding behaviour. I went with location.href because it had the most aligned encode/decode behaviour for getting and setting (IIRC, one of the browsers messed with spaces when using location.hash). If the test suite runs correctly with this patch, then we're good.
comment:10 Changed 8 years ago by
| Milestone: | future → 1.7.1 |
|---|
comment:11 Changed 8 years ago by
Tested the patch above, and we're good to go for the non replace case (there are no encoding differences for the setting case, only the getting case).
I'm working on an updated patch for the replace case. The key is to read location.href first, and to call location.replace with the fully qualified URL. Firefox only applies the base tag when setting location.href, not when getting it.
comment:12 Changed 8 years ago by
| Milestone: | 1.7.1 → 1.8 |
|---|
Bumping to 1.8; can backport if there is a solid argument.
comment:13 Changed 8 years ago by
Tested in Chrome and the test fails. First button does not change the page nor the hash, second button changes the hash and browses to the page referenced by base
comment:14 Changed 7 years ago by
| Milestone: | 1.8 → 2.0 |
|---|
1.8 has been tagged; moving all outstanding tickets to next major release milestone.
comment:15 Changed 4 years ago by
| Milestone: | 2.0 → 1.11 |
|---|---|
| Owner: | changed from Rob Retchless to bill |
| Status: | new → assigned |
comment:16 Changed 4 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
retchless, I marked this for 1.5, but if you do not think you will have a patch ready by then, just give a holler.