Caret mode no longer on by default in View Source window

RESOLVED FIXED in mozilla1.8rc1

Status

()

Toolkit
View Source
RESOLVED FIXED
13 years ago
10 years ago

People

(Reporter: Uri Bernstein (Google), Assigned: Uri Bernstein (Google))

Tracking

({fixed1.8, regression})

Trunk
mozilla1.8rc1
fixed1.8, regression
Points:
---
Bug Flags:
blocking1.8rc1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

13 years ago
The View Source window no longer displays a caret (when caret browsing is off).
Arrow keys scroll the view, instead of moving the (now missing) caret.

This regressed both on the trung and on the 1.8 branch. Regression window on the
branch is between 2005-09-30-06 and 2005-10-01-06.

See bug 254078 for where caret browsing was originally introduced to Firefox's
View Source window.
(Assignee)

Updated

13 years ago
Flags: blocking1.8rc1?

Comment 1

13 years ago
not going to block the release on a view source caret browser problem.
Flags: blocking1.8rc1? → blocking1.8rc1-
(Assignee)

Comment 2

13 years ago
This regressed on the trunk during essentially the same range as on the branch.
Here is a list of bugs which were referenced in checkins on both the trunk and
the branch during that window. Nothing seems directly releveant. 

bug 99224, bug 222919, bug 278472, bug 288054, bug 295815, bug 300453, bug
301776, bug 304089, bug 304330, bug 304388, bug 306576, bug 306658, bug 307076,
bug 307158, bug 307547, bug 307874, bug 309335, bug 309348, bug 309606, bug
309784, bug 310226, bug 310372, bug 310456, bug 310480, bug 310569.
(Assignee)

Comment 3

13 years ago
This was regressed by the fix to bug 307874.

Apparently the updateStatusBar() function introduced in that patch somehow
conflicts with the updateStatusBar() function in viewSource.js, which is
responsible for turning on caret browsing.
Blocks: 307874
OS: MacOS X → All
Hardware: Macintosh → All
(Assignee)

Comment 4

13 years ago
Created attachment 200183 [details] [diff] [review]
patch

Suggesting a patch myself in hope to get this fixed for 1.8.

Simply rename the new function to something else so that it won't conflict with
the existing one.
Attachment #200183 - Flags: review?(mconnor)
Comment on attachment 200183 [details] [diff] [review]
patch

viewSource.xul includes both scripts so this is ecpected.

r=mano.

This is very safe and should be taken on the branch
Attachment #200183 - Flags: review?(mconnor)
Attachment #200183 - Flags: review+
Attachment #200183 - Flags: approval1.8rc1?
Sorry this is my regression. And Thank you Uri's work.
I filed bug 313149. We should not reproduce like this regression.
Checking in findBar.js;
/cvsroot/mozilla/toolkit/components/typeaheadfind/content/findBar.js,v  <-- 
findBar.js
new revision: 1.31; previous revision: 1.30
done
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Updated

13 years ago
Attachment #200183 - Flags: approval1.8rc1? → approval1.8rc1+
Checking in toolkit/components/typeaheadfind/content/findBar.js;
/cvsroot/mozilla/toolkit/components/typeaheadfind/content/findBar.js,v  <-- 
findBar.js
new revision: 1.21.2.10; previous revision: 1.21.2.9
done
Keywords: fixed1.8
Target Milestone: --- → Firefox1.5rc1
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.