Closed
Bug 811815
Opened 12 years ago
Closed 12 years ago
[Browser] A href links are not underlined/showing as links in Browser
Categories
(Firefox OS Graveyard :: General, defect, P1)
Tracking
(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)
RESOLVED
FIXED
blocking-basecamp | + |
People
(Reporter: nhirata, Assigned: dougt)
References
Details
(Keywords: otoro, regression, unagi)
Attachments
(2 files)
18.12 KB,
image/png
|
Details | |
1.28 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
## Environment : Unagi phone, build 20121114 ## Repro : 1. launch browser 2. go to http://people.mozilla.com/~nhirata/html_tp/AndroidLinks.html ## Expected : 1. A href links have an underline/color so it's easy to determine it's a link ## Actual : 1. it looks solid black. Hard to tell they are links ## Note : 1. usability issue + I think this is a regression?
Updated•12 years ago
|
Component: Gaia::Browser → General
Comment 1•12 years ago
|
||
This looks like a platform issue... I don't *think* this can be effected by a CSS issue in the browser app itself?
Assignee | ||
Updated•12 years ago
|
blocking-basecamp: ? → +
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → doug.turner
Comment 2•12 years ago
|
||
Definitely a regression also - I know this was working before.
Keywords: regression
Assignee | ||
Updated•12 years ago
|
Keywords: regressionwindow-wanted
Updated•12 years ago
|
OS: Android → Gonk (Firefox OS)
Assignee | ||
Comment 5•12 years ago
|
||
This was most likely caused by bug 799609. Please see comment #4 where gal says that this is a v2 feature. renom'ing for further consideration.
blocking-basecamp: + → ?
Comment 6•12 years ago
|
||
(In reply to Doug Turner (:dougt) from comment #5) > This was most likely caused by bug 799609. Please see comment #4 where gal > says that this is a v2 feature. renom'ing for further consideration. Uhh...how is this a v2 feature when this was working before?
Comment 7•12 years ago
|
||
> This was most likely caused by bug 799609. "Link coloring" refers to coloring visited links purple. I don't think bug 799609 is involved here. Or, if it is, this is an entirely unexpected result, from at least my perspective.
Comment 8•12 years ago
|
||
Again, this is an obvious blocker. You do not have to look hard to find webpages which are rendered unusable by this bug.
Comment 9•12 years ago
|
||
(In reply to Justin Lebar [:jlebar] from comment #8) > Again, this is an obvious blocker. You do not have to look hard to find > webpages which are rendered unusable by this bug. +1
Assignee | ||
Comment 10•12 years ago
|
||
so, this is about the links not being underlined (colorization is going to be busted for v.1)
blocking-basecamp: ? → +
Comment 11•12 years ago
|
||
(In reply to Doug Turner (:dougt) from comment #10) > so, this is about the links not being underlined (colorization is going to > be busted for v.1) The links should be underlined and blue, without places. They're currently not underlined and black. With places, a link should be underlined and blue or purple, depending on whether it has been visited. Getting specifically this color-changing behavior is what we punted on.
Assignee | ||
Comment 12•12 years ago
|
||
> I don't think bug 799609 is involved here.
fwiw, Enabling places fixes the problem. Patching coming up to fix the default state/color of links.
Assignee | ||
Comment 13•12 years ago
|
||
i am not sure this is entirely correct. To avoid risk, maybe we may want to just set self->mLinkState to eLinkState_Unvisited when mHistory is null. Thoughts?
Attachment #686236 -
Flags: review?(justin.lebar+bug)
Assignee | ||
Updated•12 years ago
|
Keywords: regressionwindow-wanted
Comment 14•12 years ago
|
||
> To avoid risk, maybe we may want to just set self->mLinkState to eLinkState_Unvisited
> when mHistory is null.
Yeah, that seems safer, in terms of landing on Beta.
Also, I'm not familiar with this code; I'd prefer if bz reviewed.
Assignee | ||
Updated•12 years ago
|
Attachment #686236 -
Flags: review?(justin.lebar+bug) → review?(bzbarsky)
Comment 15•12 years ago
|
||
Comment on attachment 686236 [details] [diff] [review] patch v.1 r=me. This definitely makes sense: we're in Unknown, we know we have an href, so we have nothing to lose by going into Unvisited.
Attachment #686236 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 16•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/7bb68db8ab5f
Assignee | ||
Comment 17•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/977ff5b5a332 https://hg.mozilla.org/releases/mozilla-beta/rev/df0ed6a8b137
status-firefox18:
--- → fixed
status-firefox19:
--- → fixed
Comment 18•12 years ago
|
||
Setting priority based on triage discussions. Feel free to decrease priority if you disagree.
Priority: -- → P1
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 19•12 years ago
|
||
This hasn't landed on m-c yet.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Heh, my B.
Comment 21•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/7bb68db8ab5f
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•